On Wed, 10 Mar 2010, keith 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.

I'm sure one could easily write a patch which would break a 3.7+LPF 
image, but not a 3.10.2+LPF image.

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

I'm sure Nicolas' patches don't conflict with each other. But they 
conflict with my (never published) #lowBit, #highBit, etc patches.

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

We can do that anytime, can't we? I think it's not urgent to have a kernel 
image. If we get there in 6 months or a year, it doesn't really matter to 
me.

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

Actually the Trunk process is similar to what you wanted to do, but it 
doesn't use mantis at all and it's not automatic. Think about it like 
this:
- every Monticello Configuration is a new release (we are at 133 at the 
moment)
- we edit patches according to a fixed point (the last MC configuration)
- we even do it in an iterative, distributed and collaborative way with MC
- everyone can contribute from it's own image with Squeak-based tools
- you can update your image whenever you want to a newer release (MC 
configuration)

Of course you can't cherry pick patches, but that doesn't work with your 
process (see above).


Levente

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