[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

critical issues

From: Graham Percival
Subject: critical issues
Date: Mon, 27 Dec 2010 23:00:47 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

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

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

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.

- Graham

reply via email to

[Prev in Thread] Current Thread [Next in Thread]