[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP-PROP 8: issue priorities (probable 2)

From: Janek Warchoł
Subject: Re: GOP-PROP 8: issue priorities (probable 2)
Date: Sat, 20 Aug 2011 14:32:08 +0200


2011/8/16 Graham Percival <address@hidden>:
> Minor update for clarity and discussion from the past few days.
> We're aiming to accept the final proposal on Thursday.
> ** 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
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]