[Top][All Lists]

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

GOP-PROP 8: issue priorities (probable decision)

From: Graham Percival
Subject: GOP-PROP 8: issue priorities (probable decision)
Date: Wed, 10 Aug 2011 09:46:06 -0700
User-agent: Mutt/1.5.20 (2009-06-14)

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.

** 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


    * 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

      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

- Graham

reply via email to

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