GOP-PROP 8: issue priorities

[Graham Percival]

I'm expecting a moderate amount of discussion for this one.

http://lilypond.org/~graham/gop/gop_8.html


** Proposal summary

At the moment, a stable release is entirely dependent on the
number of Critical issues, but there’s some questions about
precisely what a “Critical issue” should be. Clarity about other
priority levels is also sought.

Issues which hold back future development will be given higher
priority than other issues.


** Rationale

Bug squad members are confused, users are confused, and (to a
certain extent) Graham just makes up the rules for “Critical” as
he goes along. Let’s get some clarity here.

Giving priority to issues which hinder development may be
contraversional. However, take a hard look at our issue tracker.
We have over 600 open bugs or patches to review. At one point,
this number was in the low 60s. The task of maintaining lilypond –
let alone adding large new features – cannot be handled by the
current development team alone. We need to be more efficient in
how current developers work, and we need to make it easier and
more fun for new contributors. Something which makes it impossible
for somebody to contribute is therefore more important than any
graphical output problem (with the possible exception of
regressions).


** Proposal details

Priority-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 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, I want to
hear about them so that we can document those exceptions.

    * any program behaviour which is unintentionally worse than
      the previous stable 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
      downgrade a regression to priority-medium.
    * anything which stops contributors from helping out (e.g.
      lily-git.tcl not working, source tree(s) not being
      available). 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. 

Priority-high:

    * any failure to build make or make doc which does not fall
      under the priority-critical definition.
    * 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). 

Priority-medium:

    * highest level for graphical output problems
    * highest level for undocumentated new features 

Priority-low:

    * less important graphical output problems 

Priority-postponed:

    * No fix expected for at least two years. 

Implementation notes


Cheers,
- Graham