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. 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. 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.

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
>
>