Re: clear policy discussions

[Trevor Daniels]

David Kastrup wrote Friday, July 13, 2012 4:27 PM


> Janek Warchoł <address@hidden> writes:
>
>> This is important, too, because Graham won't always be the Project
>> Manager.  It's also not guaranteed that there'll always be an
>> experienced developer with sufficient time to handle release tasks.
> 
> I just don't buy the "experienced developer" thing.  Currently we let
> our stable release process effectively be governed by randomness: we are
> waiting for a large gap in the Poisson process detecting regressions.
> If we instead delegated that decision to a moron without a clue, he
> would likely try to figure out from others what he is supposed to do.
> Which would be a large step forward in contrast to what we do now.

Three of us at least seem to take the view that rigid rules
governing the making of a stable release has not worked
well.  So we are looking to replace those rules with a process
that involves intelligent decision-making.  What choices do
we have?

a) a release-meister with responsibility to take all decisions.
That's what Han-Wen used to do, I believe.  It worked
quite well, although Graham will have more of an inside view
than I.  Would need to be someone with a similarly wide 
overview.

b) a release manager who takes final decisions, but only
after due consultation.  Bugs would be classified as release-
blocking or not, and blocks would also be imposed while
a major development was still being matured.  A release
could be made any time there were no blocks, or maybe
after some set period free of blocks.  Involves lots of 
consultation - maybe a good thing.

c) a more rule-bound system, but with more flexibility.
Janek's suggestion is an example.

It would be useful to hear views on which of these would
be preferred, so we can then concentrate on honing it.

Trevor