2010/3/10 Levente Uzonyi <leves at elte.hu>:
> On Wed, 10 Mar 2010, keith wrote:
>
>>
>> On 10 Mar 2010, at 13:39, Nicolas Cellier wrote:
>>
>>> Keith,
>>> I won't try to distinguish what I consider true and false assertions
>>> here, and will stay positive.
>>> It's good that you have a vision, and for sure a vision larger than
>>> squeak-trunk patch process.
>>> But... You have to invent a process simple enough to attract
>>> participating people.
>>> Otherwise, you fail, no matter how noble your causes are.
>>>
>>> Cheers
>>>
>>> Nicolas
>>
>> 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
>

Yes, I personnaly posted several uncompatible patches, so "manual"
review is necessary, and the image still is an efficient support for
that.
At the end, a different patch would be needed for squeak 3.9, 3.10,
trunk or Pharo, and as long as the code is on mantis, it is dead.
Maybe using automation to make it live - as Keith started - could
help, but under express condition to have good test coverage.
Also, automation is only good for detecting the issues, not really for
solving them, so I'm not fully convinced for the Kernel.
I presume automation should work better with packages, but beware of
combinatorial if you want to assert groups of packages...

Nicolas

>>
>> Keith
>>
>>
>
>