2010/3/10 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 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
>

I also believe in using RB 'lint' rules to detect non portable code,
and eventually rewrite rules to help updating packages.
That's not panacea, but a tool among others.

Nicolas

>>>
>>> Keith
>>>
>>>
>>
>>
>