[snip long-ish discussion]
OK, I think we reached a conclusion on this and so would like to make a
patch. I propose:
"
Priority-Critical: LilyPond segfaults, a regression (see below) against a
previous stable version or a regression against a fix developed for this
version. This does not apply where the "regression" occurred because a
feature was removed deliberately - this is not a bug.
"
At the bottom of this section, add:
"
Note that these are initial classifications and can be subject to change by
others in the development team. For example, a regression against an old
stable version which hasn't been noticed for a long time and which in
unlikely to get fixed could be downgraded from Priority-Critical by one of
the programmers.
"
In "Other items"
"
Regression: it used to work intentionally in an earlier stable release. If
the earlier output was accidental (i.e. we didn't try to stop a collision,
but it just so happened that two grobs didn't collide), then changing the
output does not count as a regression.
To help decide whether the change is a regression, and therefore should be
Priority-Critical, please adopt the following process:
1. Are you certain the change is OK? If so, do nothing.
2. Are you certain that the change is bad? Add it to the tracker as a
Critical issue, regression.
3. If you're not certain either way, add it to the tracker as a Critical
issue, regression but be aware that it may be recategorised or marked
invalid.
"
--
Phil Holmes
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
