----- Original Message -----
From: "Graham Percival" <gra...@percival-music.ca>
To: <lilypond-devel@gnu.org>
Cc: "Phil Holmes" <em...@philholmes.net>
Sent: Tuesday, August 02, 2011 6:22 AM
Subject: GOP-PROP 8: issue priorities
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.
They may also be controversial.
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).
I wasn't around in the days of 60 bugs, but my guess for why there are so
many more now is that it's partly due to putting almost every reported
problem into the tracker, and partly due to increasing user base as well.
Another issue to tackle is how we use the priorities. We know that critical
will focus developer's minds. But there's no drive to use the other
priorities. I know that many devs work partly to make lilypond more to
their taste, but also for general good. Perhaps we could agree that, say, a
list of 10 high priorities is the current target list, and that anyone who
wnats to contribute should/can look at fixing them as part of their
contribution?
** 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.
http://code.google.com/p/lilypond/issues/detail?id=380 is an example of a
segfault marked as postponed. TBH, I don't see the point of putting in too
much work stopping lilypond crashing on clearly incorrect input. I do see
why we don't want other programs to crash in this situation - for me, word,
firefox, etc., would potentially cause loss of work. But given Lily's
single threaded nature, crashing on clearly stupid input shouldn't delay
other more beneficial work.
* 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.
You'll recall that I added "or a regression against the current development
version". I still think this is justified - if we've done work to add a new
feature or fix a bug, it should be a critical regression if another dev's
patch takes it out again.
* 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).
So any bug in Lily that produces bad output can never be High? Or - to put
it another way, we, the developers ,only regard bugs as high when they
hinder us, not when they make you, the user's life difficult. I don't like
that. I remain of the view that the words "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." make a good definition of high.
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.
I don't actually see the point of this, given that I can find open high
priority issues almost 5 years old. Think we might as well drop it.
--
Phil Holmes
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
