Hi Stef -

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

I think you're interpreting it pretty much in the right way.

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

Look at what you asked for: You asked for all of the trouble and none of 
the reward. In other words, if I were to sign up for that job in 
Balloon, I get to do the work, and you (or whoever is at the helm) gets 
to do the say. No deal, as far as I am concerned. That's not 
responsibility, that's slave labour.

If somebody (let's say a team) is to maintain that code then they are 
going to do this by their rules, and you (e.g., a Squeak release) are 
but a customer of that group. And although the customer certainly has a 
say it doesn't mean the group will jump when you say it and it doesn't 
mean that this group will necessarily steer into the direction you tell 
it to.

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

That's exactly the point, isn't it? If you want to do that, e.g., 
personally ensure that everything gets integrated, then your only option 
is to take ownership of all the code. But then please don't complain, 
it's been your choice ;-) Alternatively, your only option is to believe 
in an economy that scales and the only way to get there is to stand back 
and delegate. Your task should then be to *find* people who do the work 
and who feel responsible, not *do* the work (I think Goran understands 
that). The point is that the system is too big for you on a personal 
level and that it's too big for anyone and that even looking at 
subsystems like Morphic it's daunting task. You need to get this smaller 
to get people involved but to get people involved you have to trust them.

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

I mean that ever since the version where we packagized Balloon3D, 
VMMaker, Games, and some other, nothing has happened even though there 
are many things that *could* go into packages. All we've seen is talk 
and actually more stuff being added (even stuff that was not in 
packages). So the situation is such that we did one step forward (the 
version where things got smaller) and then three steps backward. And the 
way you guys work does nothing to ensure things get packagized. I mean, 
what ever happened (for example) to that long TFNR list? There were 
people lined up for lots of stuff but then, as so often, absolutely 
nothing happens!

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

That is the understatement of the century ;-)

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

See the other post. And I'll give you another example (but keep in mind 
that this is just an example for a larger class of problems; I don't 
mean to discuss the specifics of this example): In the 3.9a repository 
there is a version of ToolBuilder-Morphic which Marcus changed for some 
reason. Marcus is not in the ToolBuilder developers group, as far as I 
know he didn't talk to anyone in that group, he just went ahead and did 
a change in "Squeak 3.9". By doing so, he effectively assumes ownership 
of that package, therefore directly competing with the group who is 
working on this stuff. The proper procedure would have been to post a 
bug report that gets picked up by someone working on this code. Again, 
the point is that you need to respect someone's ownership of their code 
and that means you don't do changes over their head.

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

I agree and the answer is simple: Join the group developing this stuff. 
If you care about cleaning up Morphic, join the Morphic developers group 
and convince that group to work on these issues. But by no means you can 
just impose your views on the rest of the world (as you have done a few 
times in the past) just because you have write access and others don't. 
Because then again you are disrespecting their ownership of their own 
code. Put differently: It is *my* choice whether I want "my shitty code" 
to be rewritten, not yours. And you can bitch and moan as long and as 
loud as you want, it's still *my* code and not yours and therefore your 
say in it is *very* limited.

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

See the other post for the clarification. This is not my point here.

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

Oh, this is great. You complain over me pointing out things that are 
broken (or did I ever complain about anything after the fact that was 
not actually broken?). So what you are basically argueing here is that 
it is my fault if someone else allows broken code to get in. Yes, I can 
see the logic behind that conclusion ;-)

Cheers,
   - Andreas