Re: GOP-PROP 8: issue priorities

[Phil Holmes]

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