lilypond-devel
[Top][All Lists]
Advanced

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

Re: critical issues


From: Graham Percival
Subject: Re: critical issues
Date: Mon, 3 Jan 2011 03:15:23 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

On Sun, Jan 02, 2011 at 04:37:35PM -0000, Phil Holmes wrote:
> "
> 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.
> "

I'm not certain what "regression against a fix developed for this
version" means.  If somebody fixes a minor bug in 2.13.15, and
that fix doesn't work in 2.13.17, I don't think that should be a
Critical bug.  If the fix works in 2.14.0 but doesn't work in
2.14.2 or 2.15.2, then I _would_ consider that a critical bug,
under the usual "regression against the past two stable versions"
rule.

> 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.
> "

This means that the "regression since the last two stable
versions" becomes an ad-hoc programmer decision, rather than an
official policy decision.  Couldn't we keep the "for example,
while developing 2.13, any regression since 2.12.x or 2.10.x
counts as a critical issue" sentence?  I think that one sentence
with exact numbers would provide much more clarity than terms like
"this version" or "previous two stable versions".


I don't mind if you want to hide the precise-version-number
example sentence somewhere where normal bug squad members won't
find it, but I think it should be in that chapter somewhere.

> 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.
> "

This is fine.

Cheers,
- Graham



reply via email to

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