On Wed, Dec 15, 2010 at 12:31:02PM -0000, Phil Holmes wrote: > ----- Original Message ----- From: "Janek Warchoł" > >I've read Issue classification and i think it would be good to add one > >more guideline concerning priority: i believe that the priority should > >depend on how widespread the issue is. Even minor problems concernning > >some basic elements (that will probably happen many times in even a > >single score) should be more important than an ugly collision that > >came from a contrived example and is not likely to happen more often > >than once or twice in hundred scores, or is related to very specific > >and complex engraving situations. > >Do you agree?
No. > Here's some suggested wording picking up this suggestion and > building on what we currently have: > > Regression- it seems to me that the distinction between regressions > against 2.12 versus 2.8 as detailed in the current definitions is > false. If something worked in 2.6 it should work in 2.8. If it > worked in 2.8 it should work in 2.10. Und so weiter. The exception > is where a feature was deliberately removed. We simply do not have the resources to fix stuff that broke 4 years ago. Hence the "two stable versions ago" rule. As long as the bug squad does its job in checking regressions, then any *future* breakage will be reported (and therefore fixed) before the next stable version. But if anything slips through the cracks and isn't noticed for years, then I'm not going to hold up another stable release for it. > * Priority-Critical: LilyPond segfaults, a regression against a > previous stable version or a regression against a fix developed for > this version. This does not apply where the "regression" occurred > because a feature was removed deliberately - this is not a bug. I can't tell if there was a difference here from the current version, but this looks fine. > * Priority-High: An issue which produces output which does not > > * Priority-Medium: normal priority. > > * Priority-Low: A minor problem which produces slightly undesirable > > * Priority-Postponed: no fix planned. Generally used for things like > Ancient notation, which nobody wants to touch. Meh. Sure, whatever. Send patch to Trevor. Look, the ugly truth is that the "priority" field -- other than "critical" -- has no effect on lilypond development. I've been heavily involved since 2003 (before this issue tracker in 2006), and that's my observation. It has no statistically significant affect whatsoever. Fighting about whether a bug should be high vs. low does NOTHING to get it fixed sooner or later. This is a volunteer project, and lilypond developers do not appear to be motived based on an arbitrary "priority" field. The main motivating factors appear to be: 1. somebody wants that notation added (or bug fixed) for a personal score 2. it "looks easy enough" to attempt 3. money (i.e. if somebody offers a bounty, or hires somebody with a grant) I don't want this thread to degrade into yet another combination of rants about our development process. We have a list of "GOP policy decisions", about half of which are directly aimed at improving our process. We are not going to discuss specifics of those proposals until 2.14 is out. In the mean time, go ahead and twiddle the definitions of priorities (as long as you leave Critical alone). But be aware that you're "rearranging deck chairs on the titanic". - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
