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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
