Re: (almost-)freezing current master

[Phil Holmes]

----- Original Message ----- 
From: <address@hidden>
To: <address@hidden>
Sent: Thursday, March 21, 2013 6:19 PM
Subject: (almost-)freezing current master


> Hey all,
>
> To prepare for 2.18, I think we can get it out fastish, but we need to 
> more or less freeze current master aside from bug fixes and documentation. 
> I have a lot of stuff on the countdown or on patch push that I'm not gonna 
> push for a few months until we get 2.18 out (Ferneyhough hairpins, repeat 
> slurs, etc.).
>
> Is everyone comfortable adopting a similar policy?  David has suggested 
> 2-months as a possible time frame, which I think is possible (there are no 
> egregious, unfixable bugs).  I can hold off this long on pushing big 
> patches.  Any longer and it starts to become tedious w/ rebasing and 
> further work and whatnot, so I am way-for an almost-freeze of current 
> master.
>
> Cheers,
> MS

I'm concerned about the number of regressions:

http://code.google.com/p/lilypond/issues/list?can=2&q=label%3ARegression

I've been guilty of the mis-classification of at least one of these 
(http://code.google.com/p/lilypond/issues/detail?id=3241) - I called it 
ugly, I should almost certainly have called it critical.  There are likely 
to be others.  I would like to revisit these and check which should be 
reclassified critical.  Finding any would block a stable release.

We also have 3 critical issues:

http://code.google.com/p/lilypond/issues/list?can=2&q=Type%3DCritical

I think these could possibly be revisited - for example, 2656.  A number of 
people have looked at this, and no resolution has been proposed.  If we know 
we can't fix something which has never been right, I don't see how we can 
block a stable release.

--
Phil Holmes