[Top][All Lists]

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

Re: GOP-PROP 8: issue priorities

From: Jan Warchoł
Subject: Re: GOP-PROP 8: issue priorities
Date: Fri, 5 Aug 2011 22:09:43 +0200

2011/8/2 Graham Percival <address@hidden>:
> There is a long history of "good programs never crash".  I think
> we should take part in that.


> Improvements to our development process won't be finished until
> the end 2011; I think it's irresponsible to actively recruit
> people until then.

Do you mean that we should wait until GLISS ends?

2011/8/2 Graham Percival <address@hidden>:
> Something which makes it impossible
> for somebody to contribute is therefore more important than any
> graphical output problem (with the possible exception of
> regressions).
> [...]
> Priority-medium:
>    * highest level for graphical output problems

I don't agree.
I agree that issues making contributions impossible should be critical
and are perhaps the most important things.  But I cannot agree that
"maintainability" issues are more important then graphical output
problems, to the extent of restricting graphical output problems to
medium and low priority!

2011/8/2 Phil Holmes <address@hidden>:
> 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.

I think it's too vague.  I'd rather say "a noticeable problem with
basic notation, except very weird or rare examples with easy
workarounds", where basic notation is defined as follows:
single-staff, single-voice music consisting of:
- notes ( = noteheads, stems, flags, beams)
- rests
- accidentals
- ties
- augmentation dots

We may wish to add dynamics, slurs and tuplets to this list, but i'm
not sure about that. is an example
of an issue that in my opinion doesn't meet above criteria (clef
change is not basic notation, an it doesn't look frequently-appearing)
and therefore shouldn't be high.

2011/8/2 Keith OHara <address@hidden>:
> I suggest that "Postponed" can mean "we're not quite sure what a proper fix
> would look like, yet".  Then we know to give this issue a different kind of
> attention, like looking in the textbooks, before we start coding.  Issues 39
> and 621 had some dead-end programming that might have been avoided (although
> dead-end programming as part of a hobby is not the end of the world).

No, i'd give a label for that.  We shouldn't mix different types of
information in priority field imo.

2011/8/2 Phil Holmes <address@hidden>:
> 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?

I don't think so.  Take my example: i do mostly mid-low priority
issues, often ones that i found myself.  That's because i don't have
skills to attack important issues with a reasonable change of success
without wasting too much time.  I don't want to spend 5 hours banging
my head on the wall trying to fix a critical issue that can be solved
by Mike/Carl/HanWen/someone else in 30 minutes; i prefer to spend
these 5 hours working on something that i understand and it interests
me.  Finally i'll learn enough to attack criticals on my own.
However, i may be wrong.

2011/8/2 James Lowe <address@hidden>:
> )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.

There was a time i thought they should be critical, but that's perhaps too much.

2011/8/4 Graham Percival <address@hidden>:
> Another thought: we could look at filling the patch countdown in
> order of priority (plus some amount of discretionary judgement if
> a patch has been waiting for a long time).

I'm not sure if i like it.  I usually work on issues that have low
priority (as explained above) and every patch takes me quite a long
time (i don't remember having any non-trivial patch pushed in less
than a week, and usually it's longer).  I noticed that when i have too
many issues open (including Frog's issues which i 'supervise' and
upload to Rietveld), i'm getting confused; i cannot remember what's
going on where (because discussions last for a long time) and so on.
Therefore i have to wait until some issues are closed - currently i'm
not doing anything because i don't want more mess in my mind :)


reply via email to

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