Graham Percival wrote Tuesday, June 26, 2012 9:55 PM > *** Summary > > Let’s drop the “any unintended change” thing, and go totally with > the regression tests. Tests pass? We can make a stable release. > Also, let’s have an official roadmap.
Rather than discussing each point separately below I prefer to make some general observations. The present proposal is too detailed and not sufficiently radical. We need to consider wider options and consequences first, before honing the details. 1. So far there have been c. 75 critical regressions under the current definition of 'critical' since 2.14. All but one have been fixed, many of them promptly. This prompt attention IMO is due only to the fact that they were deemed to block a stable release. If the only criterion is that the release compiles the (extended) regtests satisfactorily, then I doubt that adequate attention will be directed to bugs discovered after the release that would be deemed critical on the current definition. That would seriously degrade the quality of our stable releases. 2. To complete the discussion David and I were having about the possibility of using revert as an option to fix a critical bug, I looked at a few recent critical regressions, namely those which caused Release Canditates 6 and 7 to be abandoned. None of these could have been easily fixed by reversion, either because the fix was complicated, the original source was too old for revert to be safe, or the cause was external to LP. So reversion offers no easy answer. 3. I rather like the idea of leaving the decision about the time to make a stable release to an individual. That's what Han-Wen used to do in the old days, IIRC. That individual could use tests of his own devising to help him make a decision, but I would expect him/her to at least canvas views from developers before deciding. But I worry that this would still suffer from the problem I outlined in (1) above. Perhaps that release- meister could identify bugs which (s)he considers are blocking a new stable. That would get round (1), and ensure serious bugs are attended to promptly. 4. The other possibility is to adopt timed releases. Say every 6 months. The .0 release would be made with a statement about any critical bugs, which would be fixed in a .1 release. Still suffers from (1), so I don't favour this. On balance, assuming such a person could be found, I would favour a solution along the lines of (3) above. Trevor _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
