[squeak-dev] Re: Edgar from the Ostracism Re: Squeak 4.1 release candidate 2

Frank Shearar frank.shearar at angband.za.org
Wed Apr 7 20:33:11 UTC 2010


Andreas Raab wrote:
> On 4/7/2010 7:58 AM, Edgar J. De Cleene wrote:
>> On 4/6/10 1:38 PM, "Andreas Raab"<andreas.raab at gmx.de>  wrote:
>>> What I really don't understand here is why you think that it's easier to
>>> do that with change sets rather than Monticello. I've merged lots of
>>> systems and before Monticello this was an insanely painful process. I
>>> found that with Monticello this became almost reasonable; still
>>> difficult but no longer outright insane.
>>
>> Take fresh 4.0.
>> Unzip this in same folder and filein first PrepareFor311Updates.3.cs
>> Now you could update local with
>> "Utilities applyUpdatesFromDisk" using real .cs
>> Or "Utilities updateFromServer" load from trunk and made this NUMBERED 
>> .cs
>> from the first day, not several updates later.
>> Also the update number change.
> 
> But why is any of this advantageous to using Monticello? I'm not arguing 
> that you can't do what you describe but from my perspective it is
> disadvantageous because:
> 
<snip>
 >
> 3) Monticello provides context, change sets do not. I can merge versions 
> in the inbox and see what changes are done, and if they conflict with 
> changes before or after.
> 
<snip>
> 
> The third one says that the work of an integrator is much simplified. 
> You can merge changes without fear of having conflicts even if you merge 
> a distant or old version of a package.

This one leaps out at me. The maintainer/s of a package, or set of 
packages in the case of Trunk are a bottleneck. You can't really get 
around that. You probably don't _want_ to get around that, because that 
bottleneck has another name: gatekeeper.

But being a bottleneck, we really want to make the maintainers' job as 
easy as possible, both for their sanity and for the submittor's sake. 
Easy job = rapid feedback on your submission. If you make a maintainer's 
life easy, it also certainly won't hurt your code's chances of making it 
into the package.

frank



More information about the Squeak-dev mailing list