Discussing commit models (Re: [squeak-dev] Re: Compatibility (was some other subject...))

Göran Krampe goran at krampe.se
Mon Jun 29 08:16:52 UTC 2009


Hi!

Andreas Raab wrote:
> Ian Trudel wrote:
>> Don't be upset with that. It's extremely challenging to contribute to
>> Squeak. And it's time to change that. You can make your point worth on
>> the mailing list and also discuss with Squeak Oversight Board. The
>> process is likely to be painful by any mean but we should leave our
>> emotions aside and discuss about what's important for every and each
>> of us.
> 
> Indeed. I'm all ears for ideas about how we can simplify the 
> contribution process.
> 
> Cheers,
>   - Andreas

Pharo has a world writable MC inbox. And they have "sworn" to react 
quickly and review incoming stuff. That is of course a classical 
"harvesting" setup, and we have had trouble with such a bottleneck 
earlier - so I am not sure I advocate it, but if you have man power to 
do the integration, it works.

Some of us believe that a simple "commit bit" might be a way forward, 
meaning that if we (whoever "we" is) decide to trust a developer we 
simply give that developer the right to commit straight to the trunk. No 
review, no harvester, no inbox. It is trunk after all, sure, it can 
break, so what? That is what unit tests and stable/unstable is for.

We should still of course use an issue tracker and above all correlate 
our commits to issues on the tracker by including a reference to it.

Finally I think that new tools like a working DeltaStream base or MC2 
could move us into other models of interaction. Deltas could enable a 
subscribe/publish model with multiple streams, that would be an 
awesomely interesting model to work in. Let's say Igor goes berzerk :) 
and starts breaking things - then I could just unsubscribe from his 
stream, rebuild and wait until the storm settles. Or if I learn that 
Andreas has a stream with really interesting new features I would like 
to have - then I add his stream.

But the fact remains, it must be TRIVIALLY easy to commit a quick fix. 
Most quick fixes come about when someone is busy, busy doing work - and 
if it isn't easy to "fire off" a fix, then it will not be done because 
the work comes first.

In Gjallar I have experienced this lots and lots of times. I have 
submitted some of my fixes to Mantis but I am sure I have more fixes 
that I just didn't get around to send.

regards, Göran




More information about the Squeak-dev mailing list