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
