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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
