Re: issue classification: priority guidelines

[Graham Percival]

On Wed, Dec 15, 2010 at 12:31:02PM -0000, Phil Holmes wrote:
> ----- Original Message ----- From: "Janek Warchoł"
> >I've read Issue classification and i think it would be good to add one
> >more guideline concerning priority: i believe that the priority should
> >depend on how widespread the issue is. Even minor problems concernning
> >some basic elements (that will probably happen many times in even a
> >single score) should be more important than an ugly collision that
> >came from a contrived example and is not likely to happen more often
> >than once or twice in hundred scores, or is related to very specific
> >and complex engraving situations.
> >Do you agree?

No.

> Here's some suggested wording picking up this suggestion and
> building on what we currently have:
> 
> Regression- it seems to me that the distinction between regressions
> against 2.12 versus 2.8 as detailed in the current definitions is
> false.  If something worked in 2.6 it should work in 2.8. If it
> worked in 2.8 it should work in 2.10.  Und so weiter.  The exception
> is where a feature was deliberately removed.

We simply do not have the resources to fix stuff that broke 4
years ago.  Hence the "two stable versions ago" rule.

As long as the bug squad does its job in checking regressions,
then any *future* breakage will be reported (and therefore fixed)
before the next stable version.  But if anything slips through the
cracks and isn't noticed for years, then I'm not going to hold up
another stable release for it.

> * Priority-Critical: LilyPond segfaults, a regression against a
> previous stable version or a regression against a fix developed for
> this version. This does not apply where the "regression" occurred
> because a feature was removed deliberately - this is not a bug.

I can't tell if there was a difference here from the current
version, but this looks fine.

> * Priority-High: An issue which produces output which does not
> 
> * Priority-Medium: normal priority.
> 
> * Priority-Low: A minor problem which produces slightly undesirable
> 
> * Priority-Postponed: no fix planned. Generally used for things like
> Ancient notation, which nobody wants to touch.

Meh.  Sure, whatever.  Send patch to Trevor.

Look, the ugly truth is that the "priority" field -- other than
"critical" -- has no effect on lilypond development.  I've been
heavily involved since 2003 (before this issue tracker in 2006),
and that's my observation.  It has no statistically significant
affect whatsoever.

Fighting about whether a bug should be high vs. low does NOTHING
to get it fixed sooner or later.  This is a volunteer project, and
lilypond developers do not appear to be motived based on an
arbitrary "priority" field.  The main motivating factors appear to
be:
1. somebody wants that notation added (or bug fixed) for a
personal score
2. it "looks easy enough" to attempt
3. money (i.e. if somebody offers a bounty, or hires somebody with
a grant)


I don't want this thread to degrade into yet another combination
of rants about our development process.  We have a list of "GOP
policy decisions", about half of which are directly aimed at
improving our process.  We are not going to discuss specifics of
those proposals until 2.14 is out.

In the mean time, go ahead and twiddle the definitions of
priorities (as long as you leave Critical alone).  But be aware
that you're "rearranging deck chairs on the titanic".

- Graham