>
> But Keith, that's *my* pain not yours and I'm not asking you to  
> share it. If you push your contribution into the inbox, I'll find a  
> way of loading it.

Firstly, this is the way that pharo works, its the way that 3.9  
worked, this is what we looked at and decided we didn't want that  
bottleneck, it's in the original proposal.

You have the fork it is in your control. I have no guarantees that if  
I put time and effort into something you wont just reject it out of  
hand, it has happened before. I have no further guarantees that you  
will not just take the idea and implement it yourself ignoring the  
existing implementation this too has happened before several times.  
Therefore I cannot justify that time investment, you are not a safe  
bet for anyone thinking about making a significant contribution.

Secondly, been there seen that got the t-shirt. So you load it, and  
then I loose control you don't track my latest and I have to end up  
supporting my old code ad-infinitum. The 3.10 team loaded a version of  
Installer once, and then didnt bother to upgrade it to the latest  
despite requests. They then made a release with an ancient version and  
I had to support it. The auto-build process would load the latest of  
everything all the time and make a monthly/bi-monthly release.

Thirdly, you will immediately say its not up to scratch or it breaks,  
and will just say I am not loading that it is not ready. There is no  
place or process for collaborating to work on something in place until  
it is ready. i.e. there is no "unstable" breakable branch in which the  
wider community can collaborate on significant stuff within the kernel.

> If you push your contribution to Mantis, I'll find a way of loading  
> it. If you provide it as an update to Cuis I'll find a way of  
> loading it.

I still don't think that you understand. My main contribution was a  
process that allows one (or a group) to develop stuff outside of the  
image and maintain control, the very concept of passing it over for  
you to integrate manually is an anathema to me, because then I will  
have to repeatedly get the latest trunk image, and manually re-verse  
engineer what you have done to get it back out again so that I can  
work on it again back in my own working images. If trunk was built on  
the same fixed point release as my own working images then this  
wouldn't be a problem, but I am blowed if I am going to run around  
tracking every fork's integration of my contribution continuously, and  
then if a further update is needed campaign to have each fork  
maintainer be willing to re-integrate the next update all over again.

You will be able to take my changes out of cuis, because I will be  
working relative to a fixed point release of Cuis. You however are  
unable to offer me the reciprocal courtesy of making your fixes easy  
to load for me. This is the problem with trunk, it is a one way street  
and you are the diode.

> You don't have to do that if you don't feel comfortable. I can help.  
> I've done this several times, including the closure bootstrap and  
> compiled method trailers.

Yep it went in but it wont come out. Juan has baulked at redoing your  
trailers efforts for cuis, and edgar has baulked at redoing your  
closures efforts for "3.10-Minimal".

So the direction of movement of trunk is by default one way,  
gravitating away from the existing code bases there is nothing  
fundamentally, either  technically or philosophically working to draw  
forks closer together through actual code exchange.

Watch this space, System-Exports for Cuis is released in about an hour  
or so.


> It could be done for MC 1.5/1.6 as well once they're ready and pass  
> the acid test of being able to go through and load all the updates  
> that have been published so far.

Your process has no place for working on unstable stuff, and I don't  
have the time to fix MC1.5, so it gets thrown away... this it the  
whole point of having a process which is "inclusive of everyone's  
contributions" not just the perfect stuff that passes "your acid test".

Keith

> Cheers,
>  - Andreas
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100217/94ec7131/attachment.htm