[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GOP-PROP 8: issue priorities
From: |
Graham Percival |
Subject: |
GOP-PROP 8: issue priorities |
Date: |
Mon, 1 Aug 2011 22:22:05 -0700 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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
- GOP-PROP 8: issue priorities,
Graham Percival <=