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

Sure this is what we are doing with Morphic enh (we trust eddie's  
speedup, we trust romain service architecture, we trust  
PLMrefactoring and accept that they may break a bit)
we just pay attention that the system at the end still work.

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

This is what we have been trying to do, but who want/can want to 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.

Exact this is what we are doing. So may be these people should have  
access to the "update stream"
But you saw what happened when diego started to work on Morphic,  
impara got afraid and said that they would do a fast release (btw  
this will become the ultimate joke I have against the Beeper  
beep :)). So yes, yes we should go towards this model.

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

True. I was not in TFNR and I would have loved to see it working.

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

OK excellent! We have no problem to see you working on integrated  
your stuff on 3.9a but your attitude certainly lets marcus think that  
you
were not interested. So this is a good news. Are you commited to  
maintain, integrate your package in 3.9a?
Excellent news. So we added it on the list of the stuff not to let  
die because nobody pay attention.

Marcus will be more than happy I can tell you. So let us know when  
you want to start. Doug has the account info
and as soon as marcus arrive in Chile and we get script 6 load you  
can integrate your changes.

Again WHY DID NOT YOU SEND US AN EMAIL TO SAY THAT?
in 1 s this would have been solved. I think that you are a bit  
playing devil advocate here. So I will try to get
some positive feedback in the next email.

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

Come on andreas. I found that quite low level remark. You never payed  
any attention to  the work done by the Morphic Cleaning Project else
with a bit of steering they would have made great stuff. The only way  
to get people commited to do something is to pay attention to what  
they are doing.
And this is what we are trying to do:
     we contacted the guy behind PLM refactoring, services,  
preferencesBrowser so that their good stuff is not lost.
     then the next step is really to build different groups working  
on various point but as you mentioned NTFR did not deliver anything.


> Because then again you are disrespecting their ownership of their  
> own code. Put differently: It is *my* choice whether I want "my  
> shtty code" to be rewritten, not yours.
>

Except if the code is getting in the way of everybody and if lot of  
people propose fixes and nobody pay attention to it and there is no  
maintainer.
I think that you are playing with concepts here but not morphic reality.


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