github release procedure

[H. S. Teoh]

On Fri, Jan 04, 2013 at 11:54:32PM +0100, Rob T wrote:
[...]
> Even better is to also identify in the version sequence, what is a
> beta release and what is not.
> 
> AFAIAC the current 2.061 release is in a beta stage because it is
> not yet "stable". The question though, is what does "stable" mean?
> 
> For a definition, I propose something like:
> 
> All known critical bugs have been resolved, and a certain percentage
> [to be determined] of all known non-critical bugs have been
> resolved, or some function thereof. We can settle on something I'm
> sure, but right now we have no definition of what stable means, so
> that's perhaps one reason why new releases are more buggy than I
> would expect them to be. But what does that mean? It means that I
> would *not* use the new release for anything that mattered in a
> production environment, not until it stabilized to a much higher
> standard than it currently is at.
[...]

The problem is, what constitutes "stable" is a judgment call, because
which bugs are critical (or, in this case, release-critical) are also a
judgment call.

So we would need a delegated Release Manager who decides when a
particular release branch is ready to be released, and who holds high
standards of what constitutes "release-ready".

Or have some kind of voting system such that some fixed percentage of
the top-voted bugs must be fixed before something can be released.  The
bug tracker already has a voting system, but (1) people don't pay
attention to it, so the number of votes a bug gets doesn't seem to
correlate with its likelihood of getting fixed; and (2) the number of
votes you can cast is arbitrarily limited to 10, which discourages
people from using the system.


T

-- 
Don't get stuck in a closet---wear yourself out.