Re: clear policy discussions

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

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

Oh, some rules certainly do make sense.  The trick is to apply them
rather than follow them.  It makes sense to have a cooldown period of at
least two weeks to check whether any new tricks blow up around one's
ears.

But then one needs to figure out how to deal with them.  Rewind, restart
countdown, for things that happened years ago without people noticing?
That does not make sense.  For catastrophes occuring just before, more
so.  Do we need to restart countdown?  Sometimes a revert may be safe
enough.  And so on.

The rules are supposed to help us, not block us.  We need to be able to
deal _appropriately_ with them, and there is no rule set that would fit
every situation when followed blindly.

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

That's the same, essentially.  It is still the same amount of
responsibility.  We can do musical chairs if we find nobody willing to
do this all the time.

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

Basically the release manager will say "in the current situation, I
think I'll tag the release on xxxx-xx-xx if we got bugs/regressions yyyy
and zzzz fixed in a manner we can agree to be reasonably workable until
vvvv-vv-vv."  And if he doesn't, too bad.

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

Rules are nice.  But I have come to distrust "rule-bound".  If someone
does a job in the manner the others don't like, let the next step up and
do it better.

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

Well, I am obviously currently in a mood to dismiss the parliament and
declare military rule, so I probably should take a break of a few days
in this discussion.  I don't find myself able to contribute in a manner
that is actually constructive and where I find myself receptive to other
views.  Not that this would be a strong suit of mine, anyway.

-- 
David Kastrup