Need to do something - Do Not try to enhance Morphic
stéphane ducasse
ducasse at iam.unibe.ch
Thu Oct 13 05:22:56 UTC 2005
On 13 oct. 05, at 03:09, Juan Vuletich wrote:
> Hi.
>
> I have felt the urge to answer to this thread since the first mail,
> because
> what seems to have nearly burned out Stephane and Marcus is the
> MorphicSplitters changes I made. So I have a sense of guilt.
No this is not. Do not feel guilty.
> But I didn't
> know what to say. Now Andreas helped me clarify my ideas.
>
> Yes, the problem is that the Harvesters need to check everything.
Not even. This is also the sad part.
> Yes, this does not happen with clearly owned packages as those
> Andreas said. What do
> these packages have in common? They were developed outside of the
> official
> release. Several were later loaded in the release, but their
> ownership was
> not lost. Others aren't included in the release.
Exact
> We should do the same with troublesome packages, like Morphic. But
> those
> packages Andreas said were not essential to use Squeak. And Morphic is
> central to many users of Squeak. So it must work at least as well
> as it does
> currently. So giving it to someone without a having security net is
> too
> dangerous.
>
> The only solution I see, is to refrain from enhancing Morphic in the
> standard release. Only bugfixes and perhaps support for ToolBuilder
> should
> be harvested. This means discarding the MorphicSplitters stuff I
> worked on
> for 8 months. Forget about any look enhancements.
>
> I should build an alternative Morphic package, without any Etoys
> stuff and
> without anything I don't like. An owned package, owned by me, that
> shows my
> decisions and coding style. Then, anyone who happens to like it can
> load it
> in his image. And anyone who feels the urge to make his Squeak look
> "cooler"
> should do the same. At some moment in the future, it might be worth
> replacing the old messy Morphic with one of the alternatives that
> would be
> mature by the time. It could be a cleaned Morphic, or Tweak or
> whatever.
>
> (I'm talking about Morphic here. Font rendering is not part of
> Morphic. I'd
> love to see subpixel rendering of true type in the official Squeak.)
>
> Andreas, WRT, "First, since a long time back (3.4? 3.5?) nothing has
> been actually been packagized in Squeak. Oh yes, there has been *talk*
> about "how easy it would be" (hah!) but nothing has been done (and
> I put
> this finger squarely at whatever group feels itself at the helm today:
> all these groups failed *miserably* in this regard)." I hope you
> hadn't
> looked at the MorphicSplitters stuff I published a month ago. It's the
> result of a serious effort to split Morphic in packages. It has't been
> loaded in the update stream or any official version, but that does
> not mean
> we failed miserably. If you looked at it, and say that, then I feel
> offended.
>
> Cheers,
> Juan Vuletich
>
> ----- Original Message ----- From: "Andreas Raab"
> <andreas.raab at gmx.de>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Wednesday, October 12, 2005 2:20 PM
> Subject: Re: Need to do something
>
>
>
>> Chris Muller wrote:
>>
>>> To repeat the question: Is there a solution that can direct the
>>> energy
>>> we have
>>> in abundance (people creating things and "improving" existing
>>> things)
>>> toward
>>> the tasks that currently consume a the energy of a select few
>>> (harvesting
>>> these
>>> creations and improvements) in a way that gives us everything we
>>> have now
>>> (community discussion, review, testing, etc.).
>>>
>>
>> Yes, there is a solution: Stop bottle-necking the process. The
>> problem is
>> one of scaling. First, if you look around you'll notice that there
>> are
>> many parts of the larger Squeak universe, where "harvesting" works
>> just
>> fine. We only have a problem because two guys are essentially
>> responsible
>> for the entirety of Squeak (some three dozen packages?). This causes
>> endless problems, not only because it's too much of an effort for any
>> single person to steward an entire system in their spare time but
>> also
>> because no single person can have sufficient experience in each
>> individual
>> area to make good decisions.
>>
>> The alternative: Hand out responsibilities for packages. Look at
>> VMMaker,
>> SqueakMap, Seaside, Monticello, ToolBuilder, you name it. These
>> all work
>> well and Stefane and Marcus don't have to spend any time
>> whatsoever on
>> them. So if you find a few people with vested interest in an area
>> you'll
>> see that suddenly you're cutting out a whole area of work for the
>> likes of
>> Stefane and Marcus (who in turn can concentrate on those packages
>> that
>> they have a vested interest in).
>>
>> The trouble is that the current setup goes squarely against the
>> whole idea
>> of giving people responsibility. As a matter of fact, I think that
>> the
>> current working style actively stands in the way of making any
>> progress
>> here. First, since a long time back (3.4? 3.5?) nothing has been
>> actually
>> been packagized in Squeak. Oh yes, there has been *talk* about
>> "how easy
>> it would be" (hah!) but nothing has been done (and I put this finger
>> squarely at whatever group feels itself at the helm today: all these
>> groups failed *miserably* in this regard).
>>
>> Secondly, by posting package versions in their private 3.9a
>> repositories
>> for packages that are maintained externally, the committers of the
>> day are
>> actually *competing* with independent package development. This is
>> a total
>> no-no if you take responsibility seriously - if you want people to
>> feel
>> involved then their code is none of your damn business (unless
>> you're part
>> of the team) and you better respect it[*]. The only reason for
>> doing any
>> such thing would be because of an irresponsible maintainer who
>> threatens a
>> release.
>>
>> [*] As a matter of fact that is one of the main reason that
>> stopped me to
>> do anything for this community - if people who have no idea of the
>> subject
>> matter start "beautifying" my code so that it looks better to their
>> swollen eyes, then I'm out. I *know* when I'm using a pattern like
>> "foo ==
>> nil" instead of "foo ifNil:" and I expect you to respect my
>> preferences if
>> I want to emphasize a particular aspect in the code. Just looking
>> over
>> what people have done to my code in the chess game makes me want
>> to barf -
>> not one person who has touched it has had any idea whatsoever how the
>> thing works; yet they feel utterly qualified to rewrite and
>> reformat code
>> they don't even understand. Bah!
>>
>>
>>> My lame, hypothetical implementation dream that followed was
>>> meant only
>>> to
>>> provide an illustrative context for this different social
>>> approach than
>>> what we
>>> have now; i.e., distributed harvestation vs. centralized and what
>>> are the
>>> implications?
>>>
>>
>> You are absolutely right! But decentralized harvesting happens
>> because you
>> have responsible maintainers. We need a stronger sense of code
>> ownership,
>> we need a stronger sense of package ownership. Well-maintained
>> packages
>> simply don't have a "harvesting problem" the whole term is synonym
>> for a
>> major problem in the overall Squeak community setup.
>>
>> Cheers,
>> - Andreas
>>
>>
>>
>> --
>> Internal Virus Database is out-of-date.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date:
>> 8/26/2005
>>
>>
>>
>
>
>
More information about the Squeak-dev
mailing list
|