I wanted to wait until GOP started, but it seems there's a lot of
interest in this now. Here's my proposed new classifications for
issues.
There are four hopefully-not-really-contradictory goals, listed in order:
1. easy for core developers to find the type of bug they want to work on
2. easy for new developers to find the type of bug they want to work on.
3. easy for non-technical, non-musically-literate, inexperienced Bug
Meisters to add+classify items[*].
4. understandable by normal users who haven't read the issue tag
descriptions in the CG.
[*] This isn't an insult directed at our current Bug Meisters; it's
just my observation that we cannot afford to require that the bug
meister know anything about lilypond programming, or even be an expert
lilypond user. We don't have enough volunteers to be that picky. But
that's ok; remember, I did a great job (if I may say so myself)
despite not having a clue how vocal music worked, either in printed
music or in lilypond.
%% for Type, we match the first relevant item on the list.
Type-collision: keep
Type-defect: keep. However, this will now include all defects, not
just "minor code changes". (see below)
Type-documentation: keep
Type-build: new type, but I think it's worth it. Used for GUB,
makefiles, stepmake, and python scripts which are used in the build
system.
Type-scripts: convert-ly, lilypond-book, etc.
Type-enhancement: keep. However, this will now only be for "new
features", not "large code fixes". (see below)
Type-other: keep
Defect vs. Enhancement: historically, the idea was that a fix which
required a large amount of new code would be an enhancement. For
example, if two grobs were colliding but it would require a new piece
of architecture to detect the collision, this would be classified as
an enhancement.
I've had any number of debates / clarifications about this over the
years, and I'm sick of it. I'd like to say that an enhancement would
be a new user-visible feature (such as the baroque tablature stuff),
while anything that fixed the expected behaviour would be a collision
or defect.
This proposal might violate goal #1 (be convenient for core
developers). I'm willing to drop this proposal if they speak out
against it, but I'd really like this to go through, since nobody else
understands the current distinction.
%% for now, only Critical will block a stable release. In the future,
it would be nice
%% to consider High as also release-blocking, but that's not on the cards yet.
Priority-Critical: segfaults, or a regression within the last two
stable versions (right now, against 2.10.33) anything currently
ranked as High would become Critical.
Priority-High: this is Werner's "really annoying" idea.
Priority-Medium: keep. Also, any regression later against a version
less than 2.10.33 will become a medium item (unless the output is
sufficiently bad to qualify it as High).
Priority-Low: keep
Priority-Postponed: keep
At the moment I have no ideas as to how to assign any priority below
High. If anybody could propose guidelines that inexperienced,
non-musically-literate Bug Meisters could follow, that would be great.
The best I can think of is to say "try to have 20% postponed, 40%
low, 30% medium, and 10% high" and let them try to do relative
rankings.
%% Opsys: no change
%% Tags
Regression: new tag, taking over the old Priority-Regression. As stated above,
very old regressions no longer get release-blocking priority.
bounty, maintability, patch, frog, performance, security: keep
Warning: renamed from "warning-nitpick" due to the way google deals with tags.
I'm going to add a link to "label:warning" from the CG, since these are
AFAIK easy things for Frogs to work on.
Remove engraving and usability: these now get wrapped into the normal
issue type and priorities.
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
