2009/6/29 Göran Krampe <goran at krampe.se>:
> 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.

I was also discussing the same idea with Igor. A community repository
accessible to everyone. Something that we could sync with and *at
least* submit quickly unit tests and possibly fixes. Additions should
probably be handled differently. The release team can still work on
their repository and integrate valuable patches and tests as they deem
necessary.

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

Nah, Igor wouldn't do that! Would he? :)

The idea seems interesting. How would it be managed? It would be
interesting if community members could peer review streams and rate
them. We could possibly diminish the burden from release team's
shoulders if the evaluation partially shared on the community. The
community could perhaps have a direct incidence on what should be
reviewed by the release team, according to their rating.

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

I'm with you, Göran. This has to be quick and simple. Almost as a "BUY
NOW" or 1-click button. =)

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

Things do get lost, aren't they? And there is so much to review and
fix and update.

> regards, Göran

Regards,
Ian.

-- 
http://mecenia.blogspot.com/