"Phil Holmes" <m...@philholmes.net> writes: > ----- Original Message ----- > From: "David Kastrup" <d...@gnu.org> > To: "Phil Holmes" <m...@philholmes.net> > Cc: "Werner LEMBERG" <w...@gnu.org>; <lilypond-devel@gnu.org> > Sent: Saturday, April 06, 2013 3:26 PM > Subject: Re: Stable release state > > >> "Phil Holmes" <m...@philholmes.net> writes: >> >>> At present, we're actually premature in proposing a freeze to make >>> ready for a release candidate. We have a number of outstanding >>> critical bugs and regressions which need fixing before we go anywhere >>> with a new stable release. So, currently, step one is to reduce them >>> to zero. Step 2 is to propose and agree a development freeze. >> >> Tackling step 1 and step 2 in this order was seminal for 2.16 taking >> a year longer than anticipated. > > > In that case, we need to be more active in getting rid of criticals > and regressions. Are you proposing we ignore them?
I am rather proposing not to consider them the perfect excuse for keeping to shove new material into master, material that comes with its own share of criticals and regressions. The usual course of release planning involves _first_ freezing development, _then_ reducing critical problems and regressions to a release-compatible level. For an example of how this works, see <URL:http://gcc.gnu.org/develop.html>. The important thing to note here is the final stage 3 before branching: Stage 3 During this two-month period, the only (non-documentation) changes that may be made are changes that fix bugs or new ports which do not require changes to other parts of the compiler. New functionality may not be introduced during this period. Also check out the rationales for various policies. Even while our active team is smaller than that of GCC and has quite fewer fulltime developers, the main strategies are quite applicable. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel