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

[Ian Hulin]

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 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
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"
> 
> 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.
Tone this down, please.  User 'squawks' may be irritating and make the
tracker system more difficult for developers to use, but this doesn't
invalidate their concerns and ideas. What we are doing here is providing
a separate facility so we can assess the importance of user issues and
then enter them as development issues.
How about:
"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."
> 
> ** 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
>