----- Original Message -----
From: "Janek Warchoł" <lemniskata.bernoull...@gmail.com>
To: "lilypond-devel" <lilypond-devel@gnu.org>
Sent: Wednesday, December 15, 2010 11:53 AM
Subject: issue classification: priority guidelines
Hi,
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?
cheers,
Janek
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel