Re: GOP-PROP 8: issue priorities (probable 2)
On Sun, Aug 21, 2011 at 10:19:23AM +0100, Phil Holmes wrote: Think we need to change the description of this on the tracker to make it clear it's not just collisions. ok,done. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
LGTM (yeah, i'm quite late) 2011/8/16 Graham Percival gra...@percival-music.ca: On Sat, Aug 13, 2011 at 05:26:09PM +0100, Trevor Daniels wrote: I like Keith's Needs. This easily extends to several labels if we find that is desirable. Other suggestions: Thanks, I like Needs_evidence; it's general enough to apply to we need to be able to reproduce the bug, we need academic references, we need scans, etc. If we want to expand those into separate categories of this label, we'll do that in a separate GOP proposal. I want to move forward on the new Types and non-priorities without getting caught up in something that can be discussed separately. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable 2)
- Original Message - From: Graham Percival gra...@percival-music.ca * Type-ugly: replaces Type-collision, and it will include things like bad slurs in addition to actual collision. Think we need to change the description of this on the tracker to make it clear it's not just collisions. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable 2)
LGTM 2011/8/16 Graham Percival gra...@percival-music.ca: Minor update for clarity and discussion from the past few days. We're aiming to accept the final proposal on Thursday. http://lilypond.org/~graham/gop/gop_8.html ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. ** Rationale There is wide disagreement on what “priorities” should mean, or how they should be interpreted. Do they represent which “milestone” we want a fix by? How bad are crashes? How important are matters which hinder future development? Given that we treat developers as independent volunteers, the notion of an externally-imposed “priority” seems a stretch. The remaining question concerns Critical issues, and more generally, “what does a release mean?”. Our source tree is open; anybody can download and try any version. Our unstable development releases are freely available. The only distinction between git master and a “stable release” is our mark of approval. A new stable release indicates that we think the software is usable, and attracts more attention than an unstable release. In addition to user attention, it also attracts the attention of potential contributors, so we should avoid having any glaring problems which would stop somebody from contributing and turn them away – we do not want to put our “stamp of approval” on something which might cost us potential contributors. ** Proposal details We will delete “priority” altogether. The “type” system will be tweaked. Type-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 program behaviour which is unintentionally worse than the previous stable version or the current development 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 move this to a different type. * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available, lilydev being unable to compile git master, inaccurate instructions in the Contributor’s Guide 2 Quick start). 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. Problems in other chapters of the CG are not sufficient to qualify as Type-Critical. ** More new/changed types and labels Unless otherwise specified, the current types and labels will continue to be used. * Type-crash: 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, we will document those exceptions (and the issue will remain as a crash instead of documentation until the warning has been pushed). * Type-maintainability: 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). * Type-ugly: replaces Type-collision, and it will include things like bad slurs in addition to actual collision. * (label) Needs_evidence: it is not clear what the correct output should look like. We need scans, references, examples, etc. ** Shutting up users We can remind users that they can “star” an issue to indicate that they care about it. I could not possibly care less about what users think, but if any contributors want to look at that info and organize their work schedule according to that, they’re welcome to do so. Also, the stars might serve as a placebo for users. ** Implementation notes Yes, revising the current issue tracker will take a fair amount of effort, but I have a plan for this. Don’t waste time pointing this out. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable 2)
On Tue, Aug 16, 2011 at 11:20:02AM +0100, Ian Hulin wrote:
1. Some nit-picky stuff to make the proposal crystal-clear to
skim-readers like me.
See comments below embedded in the your original message text.
Thanks, all fixed.
2. I'd like to consider two types to use as additional info to the
current ones: Type-User-development and Type-Developer-development.
Interesting idea, but I don't see type-user-development as being
useful. If somebody wannts a certain behavior -- for whatever
reason -- then IMO that's a plain enhancement request.
I'll leave the door open to discussing this in a future GOP
proposal, though. But right now I want to get the remove
priorities proposal passed without getting derailed.
On 16/08/11 05:51, Graham Percival wrote:
** Shutting up users
This is a proposal. It's a bit formal, so tone down your LilyPond lists
persona a bit and call it something like
**Identifying user priorities
But I don't care about user priorities... ok, I've changed this to
reminding users about stars, and rewritten it in with a more
netural one.
We will remind users that they can 'star' issues which are important to
them. They may or may not be relevant to developing the project, or may
need to be re-worked in terms of a suggested solution. Using the star
system will allow contributors to triage user-supplied issues and then
tell the bug squad they intend to spend time on it. The contributor
then uses the Type-*** label to do this.
I used this instead:
We can remind users that they can @qq{star} an issue to indicate
that they care about it. Since we resolved to treat developers as
independent volunteers, there is no expectation that anybody will
look at those stars, but if any developer want to organize their
work schedule according to the stars, they are welcome to do so.
I like the reminder about GOP-PROP 7. (well, not an explicit
reminder, but it's still there in the independent volunteers
bit)
New version uploaded, and the final one will be tomorrow.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable 2)
Graham Percival wrote Tuesday, August 16, 2011 5:51 AM Minor update for clarity and discussion from the past few days. We're aiming to accept the final proposal on Thursday. http://lilypond.org/~graham/gop/gop_8.html LGTM Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3835 - Release Date: 08/15/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable 2)
Hi Graham, 1. Some nit-picky stuff to make the proposal crystal-clear to skim-readers like me. See comments below embedded in the your original message text. 2. I'd like to consider two types to use as additional info to the current ones: Type-User-development and Type-Developer-development. 2.1 Type-User-development: defects and enhancements that affect how LilyPond end users are able to use the project; things like the editor scheme script fired up by lily.scm, and also projects layering on Lily like LilyPondTool in JEdit, Frescobaldi. This refers to issues in our code base that the layered projects need to function, not to issues in *their* code base. 2.2 Type-Developer-Development: defects and enhancements that affect how Lily developers and contributors are able to use the project; things like interactions with GUB and git; how we structure the build directory; what is in .gitignore; how we interface with some IDE packages available like Anjuta or also JEdit (e.g. Anjuta likes to create separate directories within the build directory for producing images configured with Debug, Optimized executables etc. Also it wants to dump a .anjuta file within the git tree. Both these things = adding more things to .gitignore.) I realize you may be reluctant to open up a free-for-all re issue types but this is something I've just come across and reflects LilyPond's slightly weird position as a project in having users able to customise a compiler/interpreter as well as the developers and contributors actually hacking the code-base. Cheers, Ian On 16/08/11 05:51, Graham Percival wrote: Minor update for clarity and discussion from the past few days. We're aiming to accept the final proposal on Thursday. http://lilypond.org/~graham/gop/gop_8.html ** Proposal summary Let's get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. We will make a Type-Critical; a new stable release will only occur if there are 0 type-Critical issues. ** Rationale There is wide disagreement on what priorities should mean, or how they should be interpreted. Do they represent which milestone we want a fix by? How bad are crashes? How important are matters which hinder future development? Given that we treat developers as independent volunteers, the notion of an externally-imposed “priority†seems a stretch. The remaining question concerns Critical issues, and more generally, “what does a release mean?â€. Our source tree is open; anybody can download and try any version. Our unstable development releases are freely available. The only distinction between git master and a “stable release†is our mark of approval. A new stable release indicates that we think the software is usable, and attracts more attention than an unstable release. In addition to user attention, it also attracts the attention of potential contributors, so we should avoid having any glaring problems which would stop somebody from contributing and turn them away – we do not want to put our “stamp of approval†on something which might cost us potential contributors. ** Proposal details We will delete “priority†altogether. The “type†system will be tweaked. Type-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 program behaviour which is unintentionally worse than the previous stable version or the current development 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 move this to a different type. * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available, lilydev being unable to compile git master, inaccurate instructions in the Contributor's Guide 2 Quick start). 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. Problems in other chapters of the CG are not sufficient to qualify as Type-Critical. ** More new/changed types and labels Unless otherwise specified, the current types and labels will continue to be used. Add The new types introduced by this proposal are: this makes it clear you're not junking existing types. * Type-crash: 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, we will document those exceptions (and the issue will remain as a
RE: GOP-PROP 8: issue priorities (probable 2)
LGTM. Carl From: lilypond-devel-bounces+c_sorensen=byu@gnu.org [lilypond-devel-bounces+c_sorensen=byu@gnu.org] On Behalf Of Graham Percival [gra...@percival-music.ca] Sent: Monday, August 15, 2011 10:51 PM To: lilypond-devel@gnu.org Subject: GOP-PROP 8: issue priorities (probable 2) Minor update for clarity and discussion from the past few days. We're aiming to accept the final proposal on Thursday. http://lilypond.org/~graham/gop/gop_8.html ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. ** Rationale There is wide disagreement on what “priorities” should mean, or how they should be interpreted. Do they represent which “milestone” we want a fix by? How bad are crashes? How important are matters which hinder future development? Given that we treat developers as independent volunteers, the notion of an externally-imposed “priority” seems a stretch. The remaining question concerns Critical issues, and more generally, “what does a release mean?”. Our source tree is open; anybody can download and try any version. Our unstable development releases are freely available. The only distinction between git master and a “stable release” is our mark of approval. A new stable release indicates that we think the software is usable, and attracts more attention than an unstable release. In addition to user attention, it also attracts the attention of potential contributors, so we should avoid having any glaring problems which would stop somebody from contributing and turn them away – we do not want to put our “stamp of approval” on something which might cost us potential contributors. ** Proposal details We will delete “priority” altogether. The “type” system will be tweaked. Type-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 program behaviour which is unintentionally worse than the previous stable version or the current development 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 move this to a different type. * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available, lilydev being unable to compile git master, inaccurate instructions in the Contributor’s Guide 2 Quick start). 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. Problems in other chapters of the CG are not sufficient to qualify as Type-Critical. ** More new/changed types and labels Unless otherwise specified, the current types and labels will continue to be used. * Type-crash: 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, we will document those exceptions (and the issue will remain as a crash instead of documentation until the warning has been pushed). * Type-maintainability: 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). * Type-ugly: replaces Type-collision, and it will include things like bad slurs in addition to actual collision. * (label) Needs_evidence: it is not clear what the correct output should look like. We need scans, references, examples, etc. ** Shutting up users We can remind users that they can “star” an issue to indicate that they care about it. I could not possibly care less about what users think, but if any contributors want to look at that info and organize their work schedule according to that, they’re welcome to do so. Also, the stars might serve as a placebo for users. ** Implementation notes Yes, revising the current issue tracker will take a fair amount of effort, but I have a plan for this. Don’t waste time pointing this out. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list
Re: GOP-PROP 8: issue priorities (probable decision)
On Wed 10 Aug 2011, 22:04 Colin Campbell wrote: On 11-08-10 10:46 AM, Graham Percival wrote: * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. Perhaps more diplomatically as Type- ambiguous? type-pendinginput? -- Dmytro O. RedchukEasy to use is easy to say. Bug Squad -- Jeff Garbers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On Wed 10 Aug 2011, 09:46 Graham Percival wrote: ** More new/changed types * Type-crash: 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, we will document those exceptions (and the issue will remain as a crash instead of documentation until the warning has been pushed). * Type-maintainability: 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). * Type-ugly: replaces Type-collision, and it will include things like bad slurs in addition to actual collision. * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. No type-documentation any more? Why? Sorry, I've jumped a bit late thought. I agree that we can classify work with tags/labels; however things like docs improvement do not fit into these crash/maint/ugly/ignore, as for me. -- Dmytro O. RedchukEasy to use is easy to say. Bug Squad -- Jeff Garbers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On Wed 10 Aug 2011, 09:46 Graham Percival wrote: In case you're wondering: yes, I am serious proposing that we elminiate priorities completely, and this is not a joke. Nobody Do we want to discuss labels -- backport/invalid/invalid-verified/etc-etc or like that, as this was discussed a bit in lists? -- Dmytro O. RedchukEasy to use is easy to say. Bug Squad -- Jeff Garbers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On Mon, Aug 15, 2011 at 02:56:21PM +0300, Dmytro O. Redchuk wrote: On Wed 10 Aug 2011, 09:46 Graham Percival wrote: ** More new/changed types No type-documentation any more? Why? Sorry, I've jumped a bit late thought. That was only a list of changed types. Anything left unmentioned (i.e. docs, build, scripts, etc) will remain as before. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On Mon, Aug 15, 2011 at 03:00:05PM +0300, Dmytro O. Redchuk wrote: On Wed 10 Aug 2011, 09:46 Graham Percival wrote: In case you're wondering: yes, I am serious proposing that we elminiate priorities completely, and this is not a joke. Nobody Do we want to discuss labels -- backport/invalid/invalid-verified/etc-etc or like that, as this was discussed a bit in lists? I'm not aware of any labels that we can discuss on a policy standpoint. I know that there's some dissatisfaction with the way that invalid/duplicate/verified works, but that relies on google's infrastructure, and I'm not certain if anybody has bothered to follow this up with google yet. If there's any other concerns/proposals, I'd like to deal with them as a separate proposal anyway. There seems to be a fair amount of support for the proposal as it stands now, so I'd like to get that through, start working in that new method, and not delay it while we debate other proposals. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
Am Monday, 15. August 2011, 21:36:58 schrieb Graham Percival: I know that there's some dissatisfaction with the way that invalid/duplicate/verified works, but that relies on google's infrastructure, and I'm not certain if anybody has bothered to follow this up with google yet. http://code.google.com/p/support/issues/detail?id=2612 Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On Sat, Aug 13, 2011 at 05:26:09PM +0100, Trevor Daniels wrote: I like Keith's Needs. This easily extends to several labels if we find that is desirable. Other suggestions: Thanks, I like Needs_evidence; it's general enough to apply to we need to be able to reproduce the bug, we need academic references, we need scans, etc. If we want to expand those into separate categories of this label, we'll do that in a separate GOP proposal. I want to move forward on the new Types and non-priorities without getting caught up in something that can be discussed separately. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 8: issue priorities (probable 2)
Minor update for clarity and discussion from the past few days. We're aiming to accept the final proposal on Thursday. http://lilypond.org/~graham/gop/gop_8.html ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. ** Rationale There is wide disagreement on what “priorities” should mean, or how they should be interpreted. Do they represent which “milestone” we want a fix by? How bad are crashes? How important are matters which hinder future development? Given that we treat developers as independent volunteers, the notion of an externally-imposed “priority” seems a stretch. The remaining question concerns Critical issues, and more generally, “what does a release mean?”. Our source tree is open; anybody can download and try any version. Our unstable development releases are freely available. The only distinction between git master and a “stable release” is our mark of approval. A new stable release indicates that we think the software is usable, and attracts more attention than an unstable release. In addition to user attention, it also attracts the attention of potential contributors, so we should avoid having any glaring problems which would stop somebody from contributing and turn them away – we do not want to put our “stamp of approval” on something which might cost us potential contributors. ** Proposal details We will delete “priority” altogether. The “type” system will be tweaked. Type-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 program behaviour which is unintentionally worse than the previous stable version or the current development 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 move this to a different type. * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available, lilydev being unable to compile git master, inaccurate instructions in the Contributor’s Guide 2 Quick start). 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. Problems in other chapters of the CG are not sufficient to qualify as Type-Critical. ** More new/changed types and labels Unless otherwise specified, the current types and labels will continue to be used. * Type-crash: 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, we will document those exceptions (and the issue will remain as a crash instead of documentation until the warning has been pushed). * Type-maintainability: 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). * Type-ugly: replaces Type-collision, and it will include things like bad slurs in addition to actual collision. * (label) Needs_evidence: it is not clear what the correct output should look like. We need scans, references, examples, etc. ** Shutting up users We can remind users that they can “star” an issue to indicate that they care about it. I could not possibly care less about what users think, but if any contributors want to look at that info and organize their work schedule according to that, they’re welcome to do so. Also, the stars might serve as a placebo for users. ** Implementation notes Yes, revising the current issue tracker will take a fair amount of effort, but I have a plan for this. Don’t waste time pointing this out. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On Sat, Aug 13, 2011 at 07:12:53AM +0200, David Kastrup wrote: Keith OHara k-ohara5...@oco.net writes: Issue 1809 is an interesting test of this policy. `make test` sometimes crashes for some programmers, making it very hard for them to contribute, but it crashes in the Guile garbage collection, so we might be powerless to resolve the issue. It crashes because the internal garbage collector data structures have been clobbered. Which is likely due to some Lilypond code problem (like data available too early for collection). So it is likely that we are not powerless to resolve the issue, but since the crash is happening at a point rather remote from the likely bug and is quite sensitive to the memory layout of the code, it is really hard to track down. If it's at all relevant, we haven't heard any complaints about thsi before a month or two ago. Without a reliable test, this doesn't really help in narrowing down the scope of the problem -- but I do believe that it's due to (or at least, exacerbated by) a relatively recent lilypond code change. I think we can avoid the horns of the dilemma, though: - if it crashes regularly, (safe) contribution is impossible. But then we have a reliable (or at least reliable-ish) test case. - if it crashes very infrequently, (safe) contribution is a pain, but not impossible. Given the frequency I've heard about, I'd rank this as type-Maintainability, rather than type-Critical. With a note that if anybody can reproduce it with a command-line more than 30% of the time, we'll bump it up to type-Critical. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
David Kastrup wrote Saturday, August 13, 2011 6:12 AM It crashes because the internal garbage collector data structures have been clobbered. Which is likely due to some Lilypond code problem (like data available too early for collection). So it is likely that we are not powerless to resolve the issue, but since the crash is happening at a point rather remote from the likely bug and is quite sensitive to the memory layout of the code, it is really hard to track down. This type of problem used to occur quite frequently in 1970s IBM operating systems, when all the code of the OS ran in the same address space. The hardest bugs to find and fix were when something was clobbered in a way which caused a crash much later. In fact most of these were never resolved. The only way to make progress (when it was possible) was to identify a signature of the crash which allowed a trap to be set so a core dump could be obtained a little earlier, and repeat. Often setting the trap disturbed things in such a way that the crash no longer occurred because something less critical was being clobbered. Maybe that was a fix of some sort. Even that approach doesn't seem possible here, as we don't have access to the garbage collector. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3829 - Release Date: 08/12/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
Graham Percival wrote Thursday, August 11, 2011 8:41 PM On Thu, Aug 11, 2011 at 12:32:09PM -0700, Keith OHara wrote: On Wed, 10 Aug 2011 22:06:16 -0700, Graham Percival gra...@percival-music.ca wrote: On Thu, 11 Aug 2011 00:02:51 -0700, Trevor Daniels t.dani...@treda.co.uk wrote: Graham Percival graham at percival-music.ca writes: * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. That will work; now we can think of a name for the label. Need_clarification Need_goal What_should_Lily_do I like Colin's suggestion of Type-ambiguous. Not sure ambiguous quite captures the correct meaning, and I don't think we want Type if this is to be a label. I like Keith's Needs. This easily extends to several labels if we find that is desirable. Other suggestions: Needs_input Needs_data Needs_sources Needs_references Needs_evidence Needs_support or simply Needs_more Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3830 - Release Date: 08/12/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
Graham Percival graham at percival-music.ca writes: We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. [...] it also attracts the attention of potential contributors, so we should avoid having any glaring problems which would stop somebody from contributing and turn them away – we do not want to put our “stamp of approval” on something which might cost us potential contributors. [...] * anything which stops contributors from helping out Trevor Daniels t.daniels at treda.co.uk writes: I agree this is important, but I don't see why it should prevent a new release per se. Issue 1809 is an interesting test of this policy. `make test` sometimes crashes for some programmers, making it very hard for them to contribute, but it crashes in the Guile garbage collection, so we might be powerless to resolve the issue. Probably this will stay critical until we fix it (by some miracle) work around it assign blame, and push the bug report, upstream, or give up ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
Keith OHara k-ohara5...@oco.net writes: Graham Percival graham at percival-music.ca writes: We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. [...] it also attracts the attention of potential contributors, so we should avoid having any glaring problems which would stop somebody from contributing and turn them away – we do not want to put our “stamp of approval” on something which might cost us potential contributors. [...] * anything which stops contributors from helping out Trevor Daniels t.daniels at treda.co.uk writes: I agree this is important, but I don't see why it should prevent a new release per se. Issue 1809 is an interesting test of this policy. `make test` sometimes crashes for some programmers, making it very hard for them to contribute, but it crashes in the Guile garbage collection, so we might be powerless to resolve the issue. It crashes because the internal garbage collector data structures have been clobbered. Which is likely due to some Lilypond code problem (like data available too early for collection). So it is likely that we are not powerless to resolve the issue, but since the crash is happening at a point rather remote from the likely bug and is quite sensitive to the memory layout of the code, it is really hard to track down. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
Graham Percival wrote Thursday, August 11, 2011 6:06 AM On Thu, Aug 11, 2011 at 04:59:02AM +, Keith OHara wrote: Graham Percival graham at percival-music.ca writes: * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. In a classification of Types, I'd drop this. It is not a type of problem but rather a status of problem, and not something we will likely want to sort under. We can look in the comments to see if the desired behavior is clear before starting to program. I'm fine with that. Glad to see Keith's comment has made you change your mind. Why not use a label to indicate this? That would enable a short list of these to be displayed if someone came across a pertinent example but couldn't remember the issue number. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3825 - Release Date: 08/10/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On Wed, 10 Aug 2011 22:06:16 -0700, Graham Percival gra...@percival-music.ca wrote: On Thu, Aug 11, 2011 at 04:59:02AM +, Keith OHara wrote: Graham Percival graham at percival-music.ca writes: Type-critical: You might want to split this into two: regressions to the output of Lilypond, and critical impediments to development Why bother splitting it? I forsee an average weekly count of 2 Critical regressions, and 0.15 critical impediments to development. Good point. Probably not worth splitting them. I was merely noting that they are conceptually different. On Thu, 11 Aug 2011 00:02:51 -0700, Trevor Daniels t.dani...@treda.co.uk wrote: Graham Percival graham at percival-music.ca writes: * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. Why not use a label to indicate this? That would enable a short list of these to be displayed if someone came across a pertinent example but couldn't remember the issue number. That will work; now we can think of a name for the label. Need_clarification Need_goal What_should_Lily_do ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On Thu, Aug 11, 2011 at 12:32:09PM -0700, Keith OHara wrote: On Wed, 10 Aug 2011 22:06:16 -0700, Graham Percival gra...@percival-music.ca wrote: On Thu, 11 Aug 2011 00:02:51 -0700, Trevor Daniels t.dani...@treda.co.uk wrote: Graham Percival graham at percival-music.ca writes: * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. That will work; now we can think of a name for the label. Need_clarification Need_goal What_should_Lily_do I like Colin's suggestion of Type-ambiguous. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
On Tue, Aug 09, 2011 at 09:27:07AM +0100, Trevor Daniels wrote: Jan Warchoł wrote Tuesday, August 09, 2011 12:27 AM Because having some issue officially block stable release is the only way of seriously pushing developers to fix it? Wouldn't work. Few, if any, developers use lily-git.tcl so are unlikely to be in a position to fix it. Using lily-git.tcl and being able to fix it are completely different things. IIRC the only people who have worked on lily-git.tcl are the original author of it, Carl, and me -- none of these people actually use lily-git.tcl. Besides, lily-git.tcl is only a small fraction of the things which may stop a contributor from helping out. If savannah is down, then nobody can push (or pull) anything. Developers seem to become more productive when releases are make frequently. If releases stop, for whatever reason, development slows down. So if this is intended as a means of coercion I think it is misguided. I disagree; developers are more productive when there's more *unstable* releases; stable releases don't really affect things (other than the prospect of a stable release increasing work). No, there's no doubt in my mind that including stops development as a Critical issue would help get them solved sooner. The only question in my mind is whether this is an acceptable departure from the describe bugs in neutral terms... each contributor can interpret the results as he or she sees fit idea. I honestly think that we *should* depart from that overall idea in this case, but I'm troubled by my inability to give a convincing reason (even to myself) as to why. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
Graham Percival wrote Wednesday, August 10, 2011 9:09 AM On Tue, Aug 09, 2011 at 09:27:07AM +0100, Trevor Daniels wrote: Wouldn't work. Few, if any, developers use lily-git.tcl so are unlikely to be in a position to fix it. Using lily-git.tcl and being able to fix it are completely different things. IIRC the only people who have worked on lily-git.tcl are the original author of it, Carl, and me -- none of these people actually use lily-git.tcl. I don't believe either you or Carl needs any coercion to fix lily-git.tc. Besides, lily-git.tcl is only a small fraction of the things which may stop a contributor from helping out. If savannah is down, then nobody can push (or pull) anything. Neither can a release be made anyway. So these reasons are no justification for this policy. You still haven't convinced me it will actually have any effect. Don't get me wrong. Whether we place these issues in a critical category or not is hardly a vital decision, but here we're talking about deciding Policy. Policy decisions must be based on sound and justifiable arguments, not opinion or expediency. So my concern is that we are not following a sufficiently sound approach here. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3824 - Release Date: 08/09/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 8: issue priorities (probable decision)
I'm feeling pretty good about this one, with the exception of whether we should have a Type-ignorance or not. In case you're wondering: yes, I am serious proposing that we elminiate priorities completely, and this is not a joke. Nobody has objected yet, but if you don't think this is a good idea, please speak up. http://lilypond.org/~graham/gop/gop_8.html ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. ** Rationale There is wide disagreement on what “priorities” should mean, or how they should be interpreted. Do they represent which “milestone” we want a fix by? How bad are crashes? How important are matters which hinder future development? Assuming that “GOP-PROP 7: developers as resources” is resolved in favor of “treat developers as independent volunteers” (which seems extremely likely), the notion of an externally-imposed “priority” seems a stretch. The remaining question concerns Critical issues, and more generally, “what does a release mean?”. Our source tree is open; anybody can download and try any version. Our unstable development releases are freely available. The only distinction between git master and a “stable release” is our mark of approval. A new stable release indicates that we think the software is usable, and attracts more attention than an unstable release. In addition to user attention, it also attracts the attention of potential contributors, so we should avoid having any glaring problems which would stop somebody from contributing and turn them away – we do not want to put our “stamp of approval” on something which might cost us potential contributors. ** Proposal details We will delete “priority” altogether. The “type” system will be tweaked. Type-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 program behaviour which is unintentionally worse than the previous stable version or the current development 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 move this to a different type. * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available, lilydev being unable to compile git master, inaccurate instructions in the Contributor’s Guide 2 Quick start). 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. Problems in other chapters of the CG are not sufficient to qualify as Type-Critical. ** More new/changed types * Type-crash: 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, we will document those exceptions (and the issue will remain as a crash instead of documentation until the warning has been pushed). * Type-maintainability: 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). * Type-ugly: replaces Type-collision, and it will include things like bad slurs in addition to actual collision. * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. ** Shutting up users We can remind users that they can “star” an issue to indicate that they care about it. I could not possibly care less about what users think, but if any contributors want to look at that info and organize their work schedule according to that, they’re welcome to do so. Also, the stars might serve as a placebo for users. ** Implementation notes Yes, revising the current issue tracker will take a fair amount of effort, but I have a plan for this. Don’t waste time pointing this out. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
On Wed, Aug 10, 2011 at 10:32:01AM +0100, Trevor Daniels wrote: Graham Percival wrote Wednesday, August 10, 2011 9:09 AM Using lily-git.tcl and being able to fix it are completely different things. IIRC the only people who have worked on lily-git.tcl are the original author of it, Carl, and me -- none of these people actually use lily-git.tcl. I don't believe either you or Carl needs any coercion to fix lily-git.tc. Think of a release as more of a stamp of approval and less of coercion. Besides, lily-git.tcl is only a small fraction of the things which may stop a contributor from helping out. If savannah is down, then nobody can push (or pull) anything. Neither can a release be made anyway. Technically I could still make a release using a local git repo. Don't get me wrong. Whether we place these issues in a critical category or not is hardly a vital decision, but here we're talking about deciding Policy. Policy decisions must be based on sound and justifiable arguments, not opinion or expediency. So my concern is that we are not following a sufficiently sound approach here. Completely agreed! I've taken a stab at this with the stamp of approval concept of a release -- please take a look at the updated GOP-PROP 8...(probable decision) and let me know what you think. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
Graham, you wrote Wednesday, August 10, 2011 5:48 PM On Wed, Aug 10, 2011 at 10:32:01AM +0100, Trevor Daniels wrote: Don't get me wrong. Whether we place these issues in a critical category or not is hardly a vital decision, but here we're talking about deciding Policy. Policy decisions must be based on sound and justifiable arguments, not opinion or expediency. So my concern is that we are not following a sufficiently sound approach here. Completely agreed! I've taken a stab at this with the stamp of approval concept of a release -- please take a look at the updated GOP-PROP 8...(probable decision) and let me know what you think. Well, OK, it's a better point, if a little contrived :) I can live with it, though. Let's move on. The key point is dropping the priority field and replacing it with the stars, and I like that. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3825 - Release Date: 08/10/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
On Wed, Aug 10, 2011 at 06:44:51PM +0100, Trevor Daniels wrote: Graham, you wrote Wednesday, August 10, 2011 5:48 PM Completely agreed! I've taken a stab at this with the stamp of approval concept of a release -- please take a look at the updated GOP-PROP 8...(probable decision) and let me know what you think. Well, OK, it's a better point, if a little contrived :) I can live with it, though. Let's move on. Well, it's not /entirely/ contrived. I mean, Janek wants us to use fontforge 20110222 or higher; I want to say no way until lilydev has that version of fontforged installed. And if we ever did push such a change without lilydev being updated, I certainly wouldn't want to make a new stable release before fixing that! We haven't had many build-dependency updates in the past few years, but before that we used to require really cutting-edge libraries. I'm not opposed to requiring new libraries, and I don't care if it's something that no linux distro includes -- as long as we have a customized, downloadable, lilydev iso image available. (I could argue that anything less would be a regression, i.e. I used to be able to contribute to development, but because of changes to git master I can no longer do so. However, I'd rather make this particular case of regression explicit.) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On 8/10/11 10:46 AM, Graham Percival gra...@percival-music.ca wrote: I'm feeling pretty good about this one, with the exception of whether we should have a Type-ignorance or not. In case you're wondering: yes, I am serious proposing that we elminiate priorities completely, and this is not a joke. Nobody has objected yet, but if you don't think this is a good idea, please speak up. http://lilypond.org/~graham/gop/gop_8.html ** Proposal summary Let¹s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. We will make a ³Type-Critical²; a new stable release will only occur if there are 0 type-Critical issues. It might be less work to only have 2 priorities: Critical Ordinary Then we could continue to use the system as it exists now. But I don't feel strongly enough about it to prevent prop 8 from passing. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On 11-08-10 10:46 AM, Graham Percival wrote: * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. Perhaps more diplomatically as Type- ambiguous? Colin -- The human race has one really effective weapon, and that is laughter. -- Mark Twain ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
Graham Percival graham at percival-music.ca writes: Type-critical: You might want to split this into two: regressions to the output of Lilypond, and critical impediments to development * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. In a classification of Types, I'd drop this. It is not a type of problem but rather a status of problem, and not something we will likely want to sort under. We can look in the comments to see if the desired behavior is clear before starting to program. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
On Thu, Aug 11, 2011 at 04:59:02AM +, Keith OHara wrote: Graham Percival graham at percival-music.ca writes: Type-critical: You might want to split this into two: regressions to the output of Lilypond, and critical impediments to development Why bother splitting it? I forsee an average weekly count of 2 Critical regressions, and 0.15 critical impediments to development. I really hope that both sub-types would be fixed very quickly, and both will block a stable release. Given that every other type is likely to have between 20 and 400 issues, I don't think that it's worth splitting them. * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. In a classification of Types, I'd drop this. It is not a type of problem but rather a status of problem, and not something we will likely want to sort under. We can look in the comments to see if the desired behavior is clear before starting to program. I'm fine with that. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
Jan Warchoł wrote Tuesday, August 09, 2011 12:27 AM 2011/8/8 Trevor Daniels t.dani...@treda.co.uk: Graham Percival wrote Monday, August 08, 2011 6:06 AM Type-critical: * 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. I agree this is important, but I don't see why it should prevent a new release per se. Because having some issue officially block stable release is the only way of seriously pushing developers to fix it? Wouldn't work. Few, if any, developers use lily-git.tcl so are unlikely to be in a position to fix it. Developers seem to become more productive when releases are make frequently. If releases stop, for whatever reason, development slows down. So if this is intended as a means of coercion I think it is misguided. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3822 - Release Date: 08/08/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
Graham Percival wrote Monday, August 08, 2011 6:06 AM ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. This is a better approach than haggling over priority. We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. ** Proposal details We will delete “priority” altogether. The “type” system will be tweaked. Type-critical: [snipped] * 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. I agree this is important, but I don't see why it should prevent a new release per se. More new/changed types [snipped] * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. I don't think this is a stand-alone type. It's more a label which could be applied to several types. ** Shutting up users We can remind users that they can “star” an issue to indicate that they care about it. I could not possibly care less about what users think, but if any contributors want to look at that info and organize their work schedule according to that, they’re welcome to do so. Also, the stars might serve as a placebo for users. I like this suggestion. There are already 6 open issues with more than 7 stars, so it's already being used. In spite of that we'd need to explain more clearly how to star an issue so all users can play, with a disclaimer that some issues might not receive attention however many stars they get. It will give quite a different rating cf to the priority field. Of the 6 issues with more than 7 stars, 2 are low, 3 medium and 1 abandoned! Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1391 / Virus Database: 1520/3821 - Release Date: 08/08/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
On Mon, Aug 08, 2011 at 10:50:02PM +0100, Trevor Daniels wrote: Graham Percival wrote Monday, August 08, 2011 6:06 AM * 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. I agree this is important, but I don't see why it should prevent a new release per se. Hmm. I must admit that this rather contrasts with the we should let each contributor make their own judgement sentiment. * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. I don't think this is a stand-alone type. It's more a label which could be applied to several types. Well... it depends on how much we trust users (and even developers!) to be able to search the tracker, and/or pay attention to the labels. I'd like to make it Really Bleeding Obvious (tm) to users that an issue is in limbo; no programming will or can take place until some non-technical work is done (i.e. finding the references). The most visible sign is to have a Type specifically for such issues, but as you point out, this isn't really a type kind of thing. I guess that at the moment, I still have a slight preference for this abuse of the type system... but I could be convinced otherwise. Especially if there's another way of making this clear? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
2011/8/8 Trevor Daniels t.dani...@treda.co.uk: Graham Percival wrote Monday, August 08, 2011 6:06 AM Type-critical: * 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. I agree this is important, but I don't see why it should prevent a new release per se. Because having some issue officially block stable release is the only way of seriously pushing developers to fix it? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
2011/8/6 David Kastrup d...@gnu.org: Jan Warchoł lemniskata.bernoulli...@gmail.com writes: 2011/8/6 James Lowe james.l...@datacore.com: Users and new contributors will interpret priority as importance, though, and will naturally want their favorites to be higher on the list. That's why I suggested putting issues where we don't know exactly what Lilypond should do, as Postponed. Obviously we can't program the behavior until we know what we want it to be, and that motivates users (who might know their area of notation better than we do) to think through what they want. Hmm. Interesting point of view. Not always helpful either. A lover of artwork won't be able to tell an artist how to improve his work. He still can be more, or less satisfied with it. You can tell critics do it yourself then, and they won't be able to. But it is not their job. Good point. 2011/8/6 Wols Lists antli...@youngman.org.uk: The whole philosophy of lilypond is that beautiful music is easily playable music. *Mostly* that's true. But as a bandsman, I place a *very* high penalty on page breaks. I wish I could force lily to force music on to one, or at most two, pages. But that goes completely against the grain of what most lily people want. IIRC it should be possible to set a custom penalty on line breaks. I know asking users to categorise importance to them is hard - yes they'll often say any bug is a serious bug - but to me for example printing one last stave on page two instead of cramming it onto page one is a massive failing of lily as a master engraver. I agree. I thought about fixing this, but i decided it's too difficult for me now. But automating page layout settings are on my TODO list; let me know if you will be trying to attack it (= CC me, i often miss e-mails not cced to me). Maybe we should have some scoring system whereby things are graded both on importance to user, and ease of fixing, along with program integrity (ie how serious a programmer would rate it - segfault, buggy code, etc). My formatting issues would probably rate about 1 on ease of fix and program integrity, but the higher the average score the more critical the feature because fixing it would have a far bigger impact across the board. Hmm. I was thinking about it some time ago, but do you know what? I think that it doesn't matter so much... Until we collectively hire a programmer to help us fixing bugs (or the development team will grow two times bigger), issue priorities (other than critical) have little impact. We'll spend more time discussing this than we'll gain by results. As for now i see that the only way to have things done is to start programming, hoping that other people will join you. It's hard, i know myself. 2011/8/6 Keith OHara k-ohara5...@oco.net: On Sat, 06 Aug 2011 00:55:46 -0700, James Lowe james.l...@datacore.com wrote: OK but it still doesn't get away from the 'when do we release the next stable release' question if we only have labels? I don't think Janek was suggesting we drop the field, only that my suggestion sounds more like a label than a rank. Yes, that's what i meant. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 8: issue priorities (radical update)
Thanks for the discussion so far! Based on that, I have a radically different proposal. http://lilypond.org/~graham/gop/gop_8.html ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. ** Rationale There is wide disagreement on what “priorities” should mean, or how they should be interpreted. Do they represent which “milestone” we want a fix by? How bad are crashes? How important are matters which hinder future development? Assuming that “GOP-PROP 7: developers as resources” is resolved in favor of “treat developers as independent volunteers” (which seems extremely likely), the notion of an externally-imposed “priority” seems a stretch. ** Proposal details We will delete “priority” altogether. The “type” system will be tweaked. Type-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 program behaviour which is unintentionally worse than the previous stable version or the current development 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 move this to a different type. * 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. More new/changed types * Type-crash: 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, we will document those exceptions (and the issue will remain as a crash instead of documentation until the warning has been pushed). * Type-maintainability: 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). * Type-ugly: replaces Type-collision, and it will include things like bad slurs in addition to actual collision. * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. ** Shutting up users We can remind users that they can “star” an issue to indicate that they care about it. I could not possibly care less about what users think, but if any contributors want to look at that info and organize their work schedule according to that, they’re welcome to do so. Also, the stars might serve as a placebo for users. ** Implementation notes Yes, revising the current issue tracker will take a fair amount of effort, but I have a plan for this. Don’t waste time pointing this out. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
2011/8/6 James Lowe james.l...@datacore.com: We don't have a GOP for 'isn't there a better way to keep track of issues AND upload patches' I see though. We have, but it's not yet put on schedule. http://lilypond.org/doc/v2.15/Documentation/contributor/policy-decisions 2011/8/6 Keith OHara k-ohara5...@oco.net: I suspect Graham meant order in which to best keep the project moving. Since the project doesn't control the order in which contributors attack issues, that would really be order in which the project encourages contributors to attack issues. Sounds good to me. Still, decision depends on our views about relative importance of user needs vs. developer needs. Theoretically, satisfying developer needs is more important to keep the project moving. However, if we follow this attitude to the extreme, there will be less users (and potentially new decelopers) coming. But any interpretation of priority in the sense of importance seems useless. We differ quite a lot in our opinions of importance. I suspect Janek and I would rank issues in near-opposite order of importance. That means that any importance-type priority estimated by the contributor who opens the issue, won't really help other contributors decide what to work on next. Probably, however, we would all sort issues into roughly the same types of problems: Regressions, crashes, incorrect output, ugly output, things that get in the way of contributing, ... So, all we really need to do is make useful classifications, and admit that we won't all agree on their relative priorities. This sounds a bit like let's drop 'priority' field and use labels only :) Users and new contributors will interpret priority as importance, though, and will naturally want their favorites to be higher on the list. That's why I suggested putting issues where we don't know exactly what Lilypond should do, as Postponed. Obviously we can't program the behavior until we know what we want it to be, and that motivates users (who might know their area of notation better than we do) to think through what they want. Hmm. Interesting point of view. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
Jan Warchoł lemniskata.bernoulli...@gmail.com writes: 2011/8/6 James Lowe james.l...@datacore.com: Users and new contributors will interpret priority as importance, though, and will naturally want their favorites to be higher on the list. That's why I suggested putting issues where we don't know exactly what Lilypond should do, as Postponed. Obviously we can't program the behavior until we know what we want it to be, and that motivates users (who might know their area of notation better than we do) to think through what they want. Hmm. Interesting point of view. Not always helpful either. A lover of artwork won't be able to tell an artist how to improve his work. He still can be more, or less satisfied with it. You can tell critics do it yourself then, and they won't be able to. But it is not their job. I have had in projects of my own long histories of explaining to people why something obvious they want to is a logical impossibility, or how the blame lies with bugs and deficiencies of components outside of my control. You can get religious about it, and it becomes annoying at the twentieth repetition from somebody who does not know about the nineteen times before that. And at some point of time, you do some imprudent workaround, or some total magic, or whatever, and people stop bothering you. The compromises between the wishes of people and the technical feasible things and those you want to do are a moving target. And the responsibility for making technical and logical impossibilities disappear, to match the program better to expectations and requirements, is only something the experienced programmer can do. Sometimes the results please the user more than the programmer. It is hard to generalize this into policies, since a policy would not change its mind if enough people bother it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 8: issue priorities
Hello, But any interpretation of priority in the sense of importance seems useless. We differ quite a lot in our opinions of importance. I suspect Janek and I would rank issues in near-opposite order of importance. That means that any importance-type priority estimated by the contributor who opens the issue, won't really help other contributors decide what to work on next. Probably, however, we would all sort issues into roughly the same types of problems: Regressions, crashes, incorrect output, ugly output, things that get in the way of contributing, ... So, all we really need to do is make useful classifications, and admit that we won't all agree on their relative priorities. This sounds a bit like let's drop 'priority' field and use labels only :) - OK but it still doesn't get away from the 'when do we release the next stable release' question if we only have labels? When we don't have regressions only? regressions + crashes? Are some regressions more 'critical' than others (genuine question) ditto crashes? Also let's say I have 20 'ugly output' issues, how do I as a user show my preference for one or more of them so that a dev who has the skill and choice to work on any knows which one will benefit the project from a user's perspective? After all I see issues bumped 'down' because they seem to have been hanging about for 'ever' and no one shows an interest in it. So issues must also be able to be bumped 'up' right? Therefore Labels in this sense that are just descriptive don't help. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On 06/08/11 08:47, David Kastrup wrote: The compromises between the wishes of people and the technical feasible things and those you want to do are a moving target. And the responsibility for making technical and logical impossibilities disappear, to match the program better to expectations and requirements, is only something the experienced programmer can do. Sometimes the results please the user more than the programmer. It is hard to generalize this into policies, since a policy would not change its mind if enough people bother it. And sometimes, the user needs results that the programmer hates. At the moment, I've got a piece of music I need to clean up because it looks awful. And it looks awful because I've forced it into a straitjacket it doesn't fit properly. BUT. The whole philosophy of lilypond is that beautiful music is easily playable music. *Mostly* that's true. But as a bandsman, I place a *very* high penalty on page breaks. I wish I could force lily to force music on to one, or at most two, pages. But that goes completely against the grain of what most lily people want. Unfortunately, to me, music with page turns can far too easily be unplayable. It's all very well saying it's easier to read but that's no consolation when it's doing a fifty yard sprint down the field away from me! :-) I know asking users to categorise importance to them is hard - yes they'll often say any bug is a serious bug - but to me for example printing one last stave on page two instead of cramming it onto page one is a massive failing of lily as a master engraver. No disrespect to the programmers (heck, I'm trying to become a contributor myself, in part because I want to correct the failings I see), but by default lily does a very poor job of minimising wasted space by default on small scores. To me that's a very serious failing, but most programmers don't see that. Maybe we should have some scoring system whereby things are graded both on importance to user, and ease of fixing, along with program integrity (ie how serious a programmer would rate it - segfault, buggy code, etc). My formatting issues would probably rate about 1 on ease of fix and program integrity, but the higher the average score the more critical the feature because fixing it would have a far bigger impact across the board. Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On Sat, 06 Aug 2011 00:13:49 -0700, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: 2011/8/6 Keith OHara k-ohara5...@oco.net: order in which the project encourages contributors to attack issues. Sounds good to me. Still, decision depends on our views about relative importance of user needs vs. developer needs. Decision of the contributor on what to attack next, right? We could collectively agree how to assign priorities, right now -- without all agreeing on whether the precise spacing of notes in boring monophonic music is more or less important than making readable interesting piano music with clef changes and staff-crossings :-) On Sat, 06 Aug 2011 00:55:46 -0700, James Lowe james.l...@datacore.com wrote: This sounds a bit like let's drop 'priority' field and use labels only :) - OK but it still doesn't get away from the 'when do we release the next stable release' question if we only have labels? I don't think Janek was suggesting we drop the field, only that my suggestion sounds more like a label than a rank. When it's time for a release we make sure the Critical issues are solved. Right before a release individual contributors will probably prefer to concentrate on ugliness issues, whether we assign them High or Medium, and go back to maintenance issues after the release. Also let's say I have 20 'ugly output' issues, how do I as a user show my preference for one or more of them so that a dev who has the skill and choice to work on any knows which one will benefit the project from a user's perspective? How do you do it now? Star the issue. Post a well-considered description of what the good output would be, maybe with a reference, so the developer knows how to proceed without making a trip to the library. Complaining about how bad the bug is tends to back-fire, but sometimes we need some explanation why the buggy output is actually wrong. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
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
RE: GOP-PROP 8: issue priorities
Hello, )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 :) ) Which is why tracker items are important for issues and why I open a tracker for a Rietveld issue another dev has created if I think it is going to be significant, or if I have had to run more than one reg test or if it has more than half a dozen updates from the dev - which implies it is important enough to warrant a lot of time. It probably annoys some because they then feel obligated but this is where I think GOP 8 blurs over to GOP 7. I get a bit exhausted keeping track of it all which is a negative thing, and I know that devs would get a bit exhausted creating 'two' issues (Tracker and Rietveld) and may then feel they have to update both now it seems I am making more work for them when in fact I am just trying to keep track of it to help and Rietveld is abysmal for this. We don't have a GOP for 'isn't there a better way to keep track of issues AND upload patches' I see though. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On Fri, Aug 05, 2011 at 10:12:26PM +, James Lowe wrote: It probably annoys some because they then feel obligated but this is where I think GOP 8 blurs over to GOP 7. I get a bit exhausted keeping track of it all which is a negative thing, ... We don't have a GOP for 'isn't there a better way to keep track of issues AND upload patches' I see though. It's being worked on. Scheduling GOP stuff is a combination of what do we have available, how much time+effort do I have in the next few weeks, and how much time+effort do I think the community wants to spend on hot air for the next few weeks. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On Wed, 03 Aug 2011 15:42:55 -0700, Graham Percival gra...@percival-music.ca wrote: On Tue, Aug 02, 2011 at 07:48:12AM +, Keith OHara wrote: I'm curious first what we want the priority field to mean. [...] The more that I think about it, the more I like this interpretation of the Priority field. What interpretation is that, exactly? I suspect Graham meant order in which to best keep the project moving. Since the project doesn't control the order in which contributors attack issues, that would really be order in which the project encourages contributors to attack issues. But any interpretation of priority in the sense of importance seems useless. We differ quite a lot in our opinions of importance. I suspect Janek and I would rank issues in near-opposite order of importance. That means that any importance-type priority estimated by the contributor who opens the issue, won't really help other contributors decide what to work on next. Probably, however, we would all sort issues into roughly the same types of problems: Regressions, crashes, incorrect output, ugly output, things that get in the way of contributing, ... So, all we really need to do is make useful classifications, and admit that we won't all agree on their relative priorities. Users and new contributors will interpret priority as importance, though, and will naturally want their favorites to be higher on the list. That's why I suggested putting issues where we don't know exactly what Lilypond should do, as Postponed. Obviously we can't program the behavior until we know what we want it to be, and that motivates users (who might know their area of notation better than we do) to think through what they want. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On 2 August 2011 10:28, Phil Holmes m...@philholmes.net wrote: 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 agree, Graham's proposal is devel-based only. As a user I prefer Phil's suggestion. An issue that clearly produces a bad (unexpected) output, whereas the input was good should be given a higher consideration. The same for issues that give a poor output and that are likely to happen in almost every score produced. Thanks! Cheers, Xavier -- Xavier Scheuer x.sche...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On Tue, Aug 02, 2011 at 10:37:18AM +0200, David Kastrup wrote: Actually, I read this first as bugs in undocumented features can't have high priority, carrying the message if you don't document your new feature, we refuse to make fixing problems with it a high priority. I wasn't going for that -- rather, that normal documentation issues aren't high-priority. As long as a doc problem doesn't stop somebody from working (such as a translation page not being updated for technical reasons?), it's priority-medium. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On Tue, Aug 02, 2011 at 07:48:12AM +, Keith OHara wrote: I'm curious first what we want the priority field to mean. Probably we do not mean literally the priority with which contributors will give attention to the bugs, because contributors are volunteers driven by individual interest. 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 didn't do this in the last patch countdown, but I'm now thinking that I should have done this. One consequence of this interpretation of the Priority field means that we should probably remove priority-postponed. I mean, if somebody *does* come by and start working on ancient music, I don't want to penalize having his patches being reviewed just because nobody's been working on ancient music in the past few years! The more that I think about it, the more I like this interpretation of the Priority field. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On Aug 2, 2011, at 6:22 AM, Graham Percival wrote: ** 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. I like the first one, but I think the second needs to be tweaked a bit. If you run LilyPond on a PDF file on accident, I find that 1 time out of 3 it crashes. This may be the same for mp3 files, jpg files, etc. The second rule could be reformatted to read any segfault on an input file that users claim to be a .ly file. I like this classification scheme, but even if it were fixed, it would not solve the issue you address in the preface to this GOP - namely, the small number of developers with respect to the large number of bugs. If possible, I'd like to have a GOP at a later date on developer recruitment: I think that it is entirely possible to actively bring on new people and to try to get the tracker back down to 60ish issues. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On Tue, Aug 02, 2011 at 07:22:33AM +0100, m...@apollinemike.com wrote: On Aug 2, 2011, at 6:22 AM, Graham Percival wrote: * any segfault, regardless of what the input file looks like or which options are given. I like the first one, but I think the second needs to be tweaked a bit. If you run LilyPond on a PDF file on accident, I find I think we should still exit gracefully, even given completely junk input. Many programs achieve this; some experts in user interface call this cat testing (well, ok, fuzz testing), while security experts call this a security risk. There is a long history of good programs never crash. I think we should take part in that. I like this classification scheme, but even if it were fixed, it would not solve the issue you address in the preface to this GOP - namely, the small number of developers with respect to the large number of bugs. Recruitment is not a problem; we already turn away / waste more volunteers than we have. The first step to recruiting new contributors is to stop turning away the existing ones, and treating label:maintainability issues as serious will go a long way towards 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. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
Graham Percival graham at percival-music.ca writes: ** 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 controversial. However, take a hard look at our issue tracker. 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. I'm curious first what we want the priority field to mean. Probably we do not mean literally the priority with which contributors will give attention to the bugs, because contributors are volunteers driven by individual interest. I suggest the field is really a categorization to help contributors decide what to give attention to. Critical issues have to be addressed before a stable release, which motivates us for the sake of the project. Likewise High issues for the sake of other contributors. Priority-medium: * highest level for graphical output problems Simply for public relations, I suggest swapping High and Medium. We will be just as motivated to solve development-hindering problems if they are called Medium. 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). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
- Original Message - From: Graham Percival gra...@percival-music.ca To: lilypond-devel@gnu.org Cc: Phil Holmes em...@philholmes.net 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
Re: GOP-PROP 8: issue priorities
Graham Percival gra...@percival-music.ca writes: Priority-medium: * highest level for graphical output problems * highest level for undocumentated new features Actually, I read this first as bugs in undocumented features can't have high priority, carrying the message if you don't document your new feature, we refuse to make fixing problems with it a high priority. Now that's an interesting thought. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 8: issue priorities
Hello, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of Phil Holmes )Sent: 02 August 2011 09:29 )To: Graham Percival; lilypond-devel@gnu.org )Subject: Re: GOP-PROP 8: issue priorities ) )- Original Message - )From: Graham Percival gra...@percival-music.ca )To: lilypond-devel@gnu.org )Cc: Phil Holmes em...@philholmes.net )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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
- Original Message - From: James Lowe james.l...@datacore.com To: Phil Holmes m...@philholmes.net; Graham Percival gra...@percival-music.ca; lilypond-devel@gnu.org [snip] ) 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. It's not a big deal for me, but I think that simply leaving them as open issues works just as well. 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 +1 -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On Tue, Aug 02, 2011 at 07:48:12AM +, Keith OHara wrote: I'm curious first what we want the priority field to mean. Ding ding, I think we have a winner. That sentence is the crux of the whole thing. Probably we do not mean literally the priority with which contributors will give attention to the bugs, because contributors are volunteers driven by individual interest. I suggest the field is really a categorization to help contributors decide what to give attention to. Yes. And with that view, I think it's worth emphasizing hinders development issues. It's easy to see improvements in graphical output. It's highly visible, users praise (good) changes, etc. By comparison, look at GUB regtest produces a random 'unbound open-file' in regtests http://code.google.com/p/lilypond/issues/detail?id=1248 People looking at the regtests simply have to remember that they should ignore warning messages about 'unbound open-file'. If we have new people working on this -- say, James to check bugs, or any replacement to Phil or James when they decide that their time is better spent training a replacement and working on more sophisticated stuff -- they need to teach their replacement to ignore 'unbound open-file' warnings, but take other warnings seriously. Now, this is not a huge inconvenience... but having this floating around for a year (I didn't bother adding it to the tracker when I first noticed it) is an annoyance to people checking regtests. It sends the message that programmers don't care about the helpful users volunteering to check regtests. That's not the message I think we should be sending to each other. Priority-medium: * highest level for graphical output problems Simply for public relations, I suggest swapping High and Medium. We will be just as motivated to solve development-hindering problems if they are called Medium. Take a look at issues with label:maintainability. I submit to you that there is extremely little interest in fixing those issues. :( 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. I like that idea! Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
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. 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). ** 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. * 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. * 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). 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. Implementation notes Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
