[Top][All Lists]

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

Re: issue classification: priority guidelines

From: Phil Holmes
Subject: Re: issue classification: priority guidelines
Date: Wed, 15 Dec 2010 12:31:02 -0000

----- Original Message ----- From: "Janek Warchoł" <address@hidden>
To: "lilypond-devel" <address@hidden>
Sent: Wednesday, December 15, 2010 11:53 AM
Subject: issue classification: priority guidelines


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?


lilypond-devel mailing list

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.

* 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.

* Priority-High: An issue which produces output which does not accurately reflect the input (e.g where the user would expect an accidental, but none is shown) or which produces aesthetically poor output in a situation which could be expected to crop up frequently in real-world music. It should not be used where the problem can be avoided with a simple workaround. It can also be used to flag where new code in a development version is not functioning as it should. This level is also used for issues which produce no output and fail to give the user a clue about what’s wrong.

* Priority-Medium: normal priority.

* Priority-Low: A minor problem which produces slightly undesirable output, or which will only occur in contrived examples, or which is very easily worked around.

* Priority-Postponed: no fix planned. Generally used for things like Ancient notation, which nobody wants to touch.

Phil Holmes

reply via email to

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