[Top][All Lists]
[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
Re: critical issues, Jan WarchoĊ, 2011/01/01
Re: critical issues, Trevor Daniels, 2011/01/01
Re: critical issues, David Kastrup, 2011/01/01
Re: critical issues, David Kastrup, 2011/01/01
Re: critical issues, Phil Holmes, 2011/01/02
- Re: critical issues,
Graham Percival <=