2011/8/2 Graham Percival <gra...@percival-music.ca>: > There is a long history of "good programs never crash". I think > we should take part in that.
+1 > 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 <gra...@percival-music.ca>: > 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 <m...@philholmes.net>: > 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. +1 > 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. http://code.google.com/p/lilypond/issues/detail?id=1301 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 <k-ohara5...@oco.net>: > 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 <m...@philholmes.net>: > 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 <james.l...@datacore.com>: > )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 <gra...@percival-music.ca>: > 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 :) cheers, Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
