Re: Stable release.

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Mon, Jun 25, 2012 at 11:07:38PM +0200, David Kastrup wrote:
>> > The release blocking issues could be fixed with minor reverts.
>> 
>> The usual release blockers are not revertible.  Even if the current set
>> is get cleared out, history tells us that the time window of two weeks
>> after unstable release is unlikely to finish before the next detected
>> regression.
>
> Well, we had at least a week when the only release-critical bug
> was the po-replace translation thing.  It's a bit silly that we
> couldn't have a release due to a 5-line texinfo documentation
> thing, and in retrospect I should have done a "hostile revert"
> (especially since the commit in question didn't go through any
> review or countdown).  But since the developer survey was coming
> up, I didn't want to open any new wounds.  Also, I was more sick
> of arguments than normal, so again I didn't want to start a new
> fight.
>
> In hindsight I should have reverted it.  And if there's no clear
> offer to fix it before tomorrow, I'll revert it anyway.

I don't know.  Our current release criterion more or less is "everybody
is sick of reporting regressions or looking for them, and enough people
try looking away to get something out".

Stupidities happen.  It does not make sense to turn each into a "you are
the one who has cost us the stable release" witch hunt.  We (TM) have
invented the Patchy processes and staging/master in order to have layers
separating stupidity from tension creating consequences, causing
additional work for computers and humans, but work that can be spread
over several people pretty well.

Our release policy aims to provide the guarantee that you can upgrade
from one stable release to the next without temporary negative
consequences, meaning that any change for the worse is intentional and
going to stay.  The net win we have from that is that we only ever have
to maintain or recommend the latest stable version, for all purposes.

That goal is not realistic.  And the two-week window which we use for
deciding whether to call a release candidate a stable release is not
related to the typical lifetime of a regression, but rather to the
frequency with which we detect old regressions.  Of course this number
is correlated with the number of regressions (we can't detect
regressions that are not there), but the relation is not hard.

We need to get away from the situation where our release policies
discourage looking for bugs or doing development.  A change in that area
will have implications on the amount of "stable releases" we are willing
to even talk about.

But I also think that one prerequisite is more than one person being
able to roll a release.  "Graham, would you please roll 2.14.4, 2.16.3,
and 2.17.15 as soon as possible?" does not really cut it.  If we choose
to maintain more than one release branch, and in particular more than
one stable release branch, we should organise this in a manner where
different people can be responsible for different branches.

-- 
David Kastrup