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