Need to do something

stéphane ducasse ducasse at iam.unibe.ch
Wed Oct 12 19:09:21 UTC 2005


Hi andreas and other

Some points: because may be I'm interpreting the emails in the wrong  
sense but I have to react!

--- First we do not have abondance....I'm sorry but there is a lot to  
do and in some areas there are really missing people
and expertise.

***I basically agree with you about giving responsibility*** but we  
asked ***endlessly*** that someone take responsibility of Etoy fixes,
Morphic fixes or improvement, Balloon and nothing happened. I would  
more than happy just been able to clean the kernel and only focus on  
my area of expertise.  But marcus and me are extremely SAD to see all  
these good fixes (because most of them are good) getting lost because  
nobody cared. So we are trying to pay attention to save all this good  
energy. The look of henrik is one of the case for example even if it  
was bigger than the average fixe we collect.

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

     English: I do not understand what you mean here.

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

This is clear that the modularisation effort has not been working  
fast. But may be people out there
do not do that during their work time. Andreas indeed lot of people  
are talking. Now 3.8 took much more time to come out nearly 7 months  
or more so people may have been discouraged. I think that using MC  
and improving MC is the way to go and to dsitribute
responsibilities.

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

     I do not understand what you are saying... certainly an english  
problem.

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

Or a bad coder, morphic is full of shit: class depending on  
subclasses, deadcode, broken stuff, procedural code, functionality
been at the wrong place....and if nobody cares then we will not make  
any progress. I thought a moment that we could
throw away morphic but this not clear anymore to me and during the  
time we should get a system that is more responsive and
with less flaws.

Now this is easy to say after the fact:
"[*] 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!"

Just say that they were idiot, this is much simpler to say. You  
cannot generalize I can provide you a HUGE list where Squeak code is  
really bad.  Then what is ***worse*** if that if you would have just  
said to the MCP people that some of the rewrites they did were
dangerous/idiot/silly
     - they would have LEARNED and get a good feeling for what they  
were doing
     - the code would not have been broken
     - everything would have been better.

So my point is that you often complain after the fact (which is your  
right)
but this is the best way not to have a community, and sometimes  
giving feedback to people willing to spend
their nights to help improving the system is the only way to go,  
except if you want to stay alone.

So I agree with distributing responsibilities, we need to do a major  
effort in cutting squeak apart, but
if you have 1 hour for squeak every night and you want that the  
community still move forward and get the
idea that fixes are important/are looked and considered for  
inclusion, then more people should do the dirty work.
So my plate is full right now.

Stef



On 12 oct. 05, at 19:49, Andreas Raab wrote:

> Hi Ken -
>
> Sounds almost like what I was saying but you still insist on bottle- 
> necking it through a "harvester". Why is that? Do you feel you need  
> a harvester for anything Avi or any of the guys working on  
> Monticello do? On VMMaker? If not, why do you feel you need a  
> harvester for, say, the FFI, the Graphics subsystem, Morphic,  
> Sound, or Networking? Who, if not the people working on this part  
> of the system, could possibly decide what an appropriate resolution  
> of the issue would be? When you have responsible maintainers there  
> is simply no role for a harvester per se - there might be some  
> supporting roles (like classifying bugs or integration testing) but  
> all of these issues should be handled by the people developing the  
> package, not some guy who is in control of everything[*]. For some  
> reason even you guys who talk about decentralized development and  
> stewarding then like to fall back on total centralized control.
>
> [*] Making releases then means that you have someone who is charge  
> of integration testing and writes bug reports for the packages in  
> the release which get addressed by the people developing that package.
>
> Cheers,
>   - Andreas
>
> Ken Causey wrote:
>
>> In my opinion a big (HUGE) step in the direction towards improving  
>> this
>> situation is developing the Stewarding system where teams take
>> responsibility for image categories and packages.  The idea here  
>> is that
>> for any given class in the system there is a dedicated person (or
>> hopefully group) that has accepted reponsibility for it and has
>> undertaken to become an expert on it.  We call such a person a  
>> Steward
>> and the team under him or her a Steward Team.
>> The Harvester's job is then reduced whenever an issue appears  
>> related to
>> this class.  The Steward(s) for the class will handle the issue  
>> and come
>> to agreement on the appropriate action.  Once agreement has been  
>> reached
>> they will hand off a complete and ready solution to the  
>> Harvesters.  The
>> Harvesters then can have confidence in the solution (built up over  
>> time
>> because they have developed confidence in the Steward(s)) and can  
>> give
>> it some quick automatic checks and shove it into the update stream
>> (whatever form that happens to take).  In time once the Harvesters  
>> have
>> built up enough confidence in a particular Steward team perhaps that
>> team can simply inject fixes directly into the update stream and not
>> require any time from the Harvesters.
>> Right now Goran and I are spiking the day to day business of  
>> Stewarding
>> and trying to work out how it will work on the lowest levels.  I  
>> really
>> hope that by the end of the week I will be able to produce a document
>> explaining the concept in detail and what it entails and once more  
>> call
>> for participation by the community.
>> More soon....
>> Ken
>> On Wed, 2005-10-12 at 09:28 -0700, Chris Muller wrote:
>>
>>> I was attempting to stimulate discussion of Stef's concern from a  
>>> social angle,
>>> not so much a technical one.
>>>
>>> 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.).
>>>
>>> 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?
>>>
>>> Stef asked for ideas to make a "self-supporting" process.  Please  
>>> forgive for a
>>> moment that it will be hard to get there.  I am still just trying  
>>> to clarify
>>> where "there" is and hoping to learn something from you guys in  
>>> the process..
>>>
>>> Regards,
>>>  Chris
>>>
>>>
>>>
>>>
>>>> Message: 15
>>>> Date: Tue, 11 Oct 2005 23:55:55 +0200
>>>> From: Michael Rueger <michael at impara.de>
>>>> Subject: Re: Need to do something
>>>> To: The general-purpose Squeak developers list
>>>>     <squeak-dev at lists.squeakfoundation.org>
>>>> Message-ID: <434C34EB.5080802 at impara.de>
>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>>
>>>> Chris Muller wrote:
>>>>
>>>>
>>>>
>>>>> Stop pushing them through Mantis or any other external tool.   
>>>>> Instead, we
>>>>>
>>>>
>>>> write
>>>>
>>>>
>>>>> a program that integrates into Squeak that allows anyone to  
>>>>> submit directly
>>>>> from the alpha image.  These submissions appear on everyones  
>>>>> list.  Later
>>>>>
>>>>
>>>> the
>>>>
>>>> NIH all over again. Things never seem to be hard to implement,  
>>>> but we are having this discussion because people are running out  
>>>> of energy harvesting, let alone writing yet another tool for  
>>>> crying out loud...
>>>>
>>>> We just moved to Mantis because the other approach didn't work...
>>>>
>>>>
>>>> ------------------------------------------------------------------- 
>>>> -----
>>>>
>>>>
>>>>
>
>
>




More information about the Squeak-dev mailing list