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. Although if this were adopted we might extend the testing period a little. > 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. Trevor _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
