[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP-PROP 8: issue priorities

From: Phil Holmes
Subject: Re: GOP-PROP 8: issue priorities
Date: Tue, 2 Aug 2011 09:28:50 +0100

----- Original Message ----- From: "Graham Percival" <address@hidden>
To: <address@hidden>
Cc: "Phil Holmes" <address@hidden>
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.

** 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

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


   * 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. 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.


   * 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.


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


   * less important graphical output problems


   * 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]