[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GOP-PROP 8: issue priorities
From: |
James Lowe |
Subject: |
RE: GOP-PROP 8: issue priorities |
Date: |
Tue, 2 Aug 2011 11:38:53 +0000 |
Hello,
)-----Original Message-----
)From: address@hidden
)[mailto:address@hidden On
)Behalf Of Phil Holmes
)Sent: 02 August 2011 09:29
)To: Graham Percival; address@hidden
)Subject: Re: GOP-PROP 8: issue priorities
)
)----- 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
)
)
)
)> 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,
+1
) and partly due to increasing user base as well.
+0.25
I'd say that it was more because people like Mr O. Redchuk (and others) have
been much more 'on the case' than has ever been before to spot tracker-fodder
or add a tracker for Reitveld items that would in the past not have had any.
)>
)> 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.
and here is the rub (for me anyway) - a good example is slurs over line breaks.
It's a hard problem (so it seems) to solve, but it produces (in some cases -
all in my own personal experience) dreadful looking output. While not obviously
critical, it should be High. Even if it is hard to solve.
I don't want to get all 'mission statementy' but isn't that the point that we
all use LP, Good/beautiful output?
)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.
+1
)>
)> 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.
)
-1
No. I think it's good to keep issues 'postponed' than closed, even if they are
old. Someone someday will come and look at this, as tastes change and
developers have specific requirements or just a plain old challenge.
In the Bugzilla-driven world I sometimes work in we have a 'WONTFIX' statement
which we use for enhancements that we never intend to implement or for issues
that are not going to be fixed in the current release of our code but no longer
exist as an issue in the newer code base (i.e. the feature is deprecated for
good). That are the only two cases we ever drop issues (or if the issue
suddenly goes away when someone revisits it after a number of iterations of the
software).
If we just close/drop the tracker issue I assume it goes off the radar and so
we lose it altogether which I don't think is a good idea.
The point of the tracker is not necessarily to get it to 0 (after all if we all
sat down and thought hard we could come up with dozens if not hundreds of
enhancements that are not bugs) but that doesn't detract from the project at
all.
Maybe some people get despondent when they see a rise of 200% in 'open' tracker
issues, not me I'd say a rising and falling (and rising again) tracker rate
shows a *healthy* interest in a software project and a healthy development base.
James
- RE: GOP-PROP 8: issue priorities, (continued)
- Re: GOP-PROP 8: issue priorities, Keith OHara, 2011/08/05
- Re: GOP-PROP 8: issue priorities, Jan Warchoł, 2011/08/06
- Re: GOP-PROP 8: issue priorities, David Kastrup, 2011/08/06
- Re: GOP-PROP 8: issue priorities, Wols Lists, 2011/08/06
- RE: GOP-PROP 8: issue priorities, James Lowe, 2011/08/06
- Re: GOP-PROP 8: issue priorities, Keith OHara, 2011/08/06
- Re: GOP-PROP 8: issue priorities, Jan Warchoł, 2011/08/07
Re: GOP-PROP 8: issue priorities, Phil Holmes, 2011/08/02
- RE: GOP-PROP 8: issue priorities,
James Lowe <=
Re: GOP-PROP 8: issue priorities, David Kastrup, 2011/08/02