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.