"Trevor Daniels" <[email protected]> writes: > David Kastrup wrote Tuesday, July 10, 2012 1:19 PM > > >> "Trevor Daniels" <[email protected]> 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. >> One could try such a revert strategy on a stable release _branch_, but >> it is not unlikely to lead to cascades of reverts, since quite a few >> fixes are also intended to cure regressions by themselves. And reverts >> of increasingly older commits have increasingly stranger interactions >> with developments that happened in between (and that does not just mean >> merge conflicts). > > If such a complication did arise then that would justify requiring a > proper fix, in which case a new countdown would begin only after the > fix was in. > > 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. Then tell me again that I am coming to irrational conclusions. It is not like we are talking about surprise developments here. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
