>>
>> I think contributing patches to mantis was simple enough
>
> That's true, but most of them were never integrated, because:
> - the integrator has to have deep knowledge about the issue, the  
> patch and the system (this was much harder than now, because now the  
> creator of the patch can integrate it most of the time. IMHO this is  
> the weakest point in Pharo's contribution process, besides the lack  
> of contributors.)
> - patches to a "fixed point" can conflict with each other making  
> integration even harder
>
> Also fine grained "cherry-picking" is not a good idea, because you  
> just can't predict how the patches will interact with each other.
>
>
> Levente
>

I don't think you are understanding, we had already been using this  
process for over 2 years. It did work, and it worked for more than one  
image simultaneously, as demonstrated by LPF. It also worked for ALL  
the packages in Sake/Packages, not just for the kernel.

The bare minimal step forward 3.10-build image had 17 fixes in it, it  
demonstrated the concept well. The test script that was being used to  
generate an example 3.11-alpha had over 100 fixes in it. My production  
images have a fair few too. We didn't have a problem with this process  
at all. We were producing tools to automate and speed up this process,  
to be repeated on a monthly cycle. The work that went into that 3.11  
script was then repeated in trunk, so I wasted my time on it.

If you are stupid enough to try and integrate more than 500 fixes per  
month then of course you will have conflicts that are a problem.  
However 200-300 is perfectly doable per month. We had 100 just by  
selecting Nicolas' fixes.

The main goal of the fixes is not to fix things per-se but to  
carefully re-architect things so that they become modules that can be  
worked upon and fixed offline, by separate individuals or teams.

"trunk" hasn't even split up "System", which was the first thing that  
needed doing if you believe in modularity. We also reorganised all of  
the tests so that they go with the thing they are testing and are  
unloadable and loadable.

The trunk process is the opposite of this, in spirit because it  
doesn't even consider having a package management solution important  
enough to do first.

The fact that we didn't publish an image, was simply because the bob- 
process had not been completed up to the automated testing point, and  
that was our actual deliverable. Not that the automated build process  
using mantis didn't work. As I said it had already been proven.

One weak point in the plan is the lack of discipline within the  
community to use mantis well, and the fact that the whole system did  
not work offline, and was relatively fragile as a result. But part of  
the bob-process plan was to provide an offline code cache. Introducing  
trunk, undermined mantis as a source of good code, for any purpose,  
even supporting legacy images, and rendered the monthly bob release  
cycle process useless overnight.

K




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100310/6a63871b/attachment.htm