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 2)
- Original Message - From: "Graham Percival" * 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 : > 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)
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 lil
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 impossibl
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
