David Kastrup wrote Tuesday, July 10, 2012 4:33 PM
> "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. No, a stable release candidate can only be made when there are no extant regressions. So all regressions discovered subsquently are new, in the sense that they were previously unknown. 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 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"). Trevor _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
