critical issues

[Graham Percival]

Hi Phil,

Could we go back to the old definition of Critical issues?  I
didn't want this definition to change, since it's used for release
plans.

Priority-Critical: lilypond segfaults, or a regression occurred
within the last two stable versions.  (i.e. when developing 2.13,
any regression against 2.12 or 2.10 counts)  This does not apply
where the regression occurred because a feature was removed
deliberately.


If a feature that only worked in 2.8 or below stops working, it is
not a Critical issue.  I'm willing to discuss changing the
definition of a Critical issue after 2.14 is out, but I don't want
to change the rules of the game after two years of development.  I
want to get 2.14 out under the previous rules, and _then_ discuss
what should be changed about our release plans.


Ironically, although the current printed policy seems to be too
inclusive for Critical issues, my main concern is that bug squad
members are classifying stuff as High instead of Critical.  It's
going to be a real downer if we suddenly discover half a dozen
Crittical regressions which were "hiding" as High issues after the
first release candidate.

Could you check the recent issue classifications, and make sure
that anything which should be a Critical issue is marked
accordingly?  I'm aware of at least two issues which should be
Critical, but aren't.

Cheers,
- Graham