2010/3/10 Ken G. Brown <kbrown at mac.com>:
> At 7:01 PM +0000 3/10/10, keith apparently wrote:
>>>>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
>
> I personally used Keith's process before 'trunk' was instituted, to build a Squeak-dev image from 3.10.2, using Damien's previous scripts, via Installer, Sake/Packages and Bob the Builder. This proved out the overall process to me, and if *I* could do it, then surely anyone else could similarly have done so.
>
> Ken G. Brown
>
>

Then I want you to play a little game:
take the exact Installer script that installed my mantis patches over
3.10, apply it to latest trunk, Cuis and Pharo, and report how it
worked.

Nicolas