14.6.4.8 GOP-PROP 8 - issue priorities

We will delete the “priority” field of the issue tracker altogether. The “type” system will be tweaked.

Type-critical:

• a reproducible failure to build either make or make doc, from an empty build tree, in a first run, if configure does not report any errors.
• any program behaviour which is unintentionally worse than the previous stable version or the current development version. Developers may always use the “this is intentional”, or even the “this is an unavoidable effect of an improvement in another area”, reason to move this to a different type.
• anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available, LilyDev being unable to compile git master, inaccurate instructions in the Contributor’s Guide 2 Quick start).

  To limit this scope of this point, we will assume that the contributor is using the latest LilyDev and has read the relevant part(s) of the Contributor’s Guide. Problems in other chapters of the CG are not sufficient to qualify as Type-Critical.

More new/changed types and labels

Unless otherwise specified, the current types and labels will continue to be used. The new types introduced by this proposal are:

• Type-crash: any segfault, regardless of what the input file looks like or which options are given. Disclaimer: this might not be possible in some cases, for example certain guile programs (we certainly can’t predict if a piece of scheme will ever stop running, i.e. the halting problem), or if we rely on other programs (i.e. ghostscript). If there are any such cases that make segfault-prevention impossible, we will document those exceptions (and the issue will remain as a "crash" instead of "documentation" until the warning has been pushed).
• Type-maintainability: anything which makes it difficult for serious contributors to help out (e.g. difficult to find the relevant source tree(s), confusing policies, problems with automatic indentation tools, etc).
• Type-ugly: replaces Type-collision, and it will include things like bad slurs in addition to actual collision.

A new label will be added:

• (label) Needs_evidence: it is not clear what the correct output should look like. We need scans, references, examples, etc.

Reminding users about stars

We can remind users that they can “star” an issue to indicate that they care about it. Since we resolved to treat developers as independent volunteers, there is no expectation that anybody will look at those stars, but if any developer want to organize their work schedule according to the stars, they are welcome to do so.

Discussions

https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00019.html
https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00277.html
https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00413.html
https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00624.html

<< Back to Documentation Index

LilyPond — Contributor’s Guide v2.18.2 (stable-branch).