"Trevor Daniels" <t.dani...@treda.co.uk> writes: > David Kastrup wrote Tuesday, July 10, 2012 4:33 PM > >> "Trevor Daniels" <t.dani...@treda.co.uk> writes: >> >>> David Kastrup wrote Tuesday, July 10, 2012 1:19 PM >>> >>> >>>> "Trevor Daniels" <t.dani...@treda.co.uk> writes: >>>> >>>>> We have the technology to identify the commits that introduce bugs >>>>> fairly easily. Perhaps once the first release candidate is made we >>>>> simply say any commit that introduced a critical regression bug after >>>>> that is simply reverted, and the originator invited to resubmit after >>>>> the next stable is released. >>>> >>>> After the stable release is before the stable release. We can't freeze >>>> development while we are unable to get a sane release process going. >>>> That would be, like, permanent. >>> >>> That's not what I said. I said "once the first release candidate is >>> made". After that point we deal with new regressions by reverting, >>> and don't start a new countdown, rather than starting a new countdown >>> only after the bug is fixed, as now. That would guarantee we get a >>> stable release within the period we allow for testing the release >>> candidate. >> >> Uh, no. By far most regressions we had were old regressions. > > No, a stable release candidate can only be made when there > are no extant regressions.
No _known_ regressions was our rule. > So all regressions discovered subsquently are new, in the sense that > they were previously unknown. I think we both could spend our time better than playing word games. > It is these that I am suggesting be "fixed" by simply identifying the > commit that introduced them and reverting it (unless there are > complications, as discussed earlier.) If the new regression can be > fixed by reverting I suggest there is no need to restart the > count-down. This should greatly shorten the time to get a stable > release out. I addressed this already in a part you did not bother quoting in your previous reply. Anyway, a revert will have consequences requiring another test phase. So there is little timing advantage for not just taking the proper fix, which gets more exposure to developer testing than a diverged release candidate. The life time of a typical regression fix has been rather long: the usual clincher for stopping the next release candidate are _unrelated_ regressions. >>> I guess we really need an analysis of recent critical bugs to come >>> to a rational conclusion. >> >> <URL:http://news.lilynet.net/?The-LilyPond-Report-26#the_road_to_2_16>, >> scroll down to "Critical issues", unfold the table, read the article. > > Yes, that was an excellent start, but we still need to tie this > in to the times release candidates were made, and then see > if subsequent regressions could have been successfully 'fixed' > by reverting, before we can come to a conclusion about my > suggestion (which is what I meant by "rational conclusion"). We would not want to rush anything, would we now? -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
