On Sat, Dec 27, 2008 at 04:11:35PM +1100, Ben Finney wrote:
> The decision of whether a bug is release-critical or not is for the
> release managers to make, using the various properties of the bug
> (including but *not* limited to its severity) as input to that
> decision. They can, in fact, make
On Sat, 27 Dec 2008, Ben Finney wrote:
> Suppose the release managers decide that the division line you point
> out will, as of tomorrow, lie in a different place from where it is
> today (i.e. between a different neighbouring pair of severity
> levels). Suppose further that their reasoning for thi
Russ Allbery writes:
> Ben Finney writes:
>
> > So, it's not correct for anyone but a release manager to decide
> > “this bug is/is not release-critical, so I'll change the
> > severity”; that is a perversion of the meaning of the severity
> > field. You can argue about whether a bug fits the d
On Sat, 27 Dec 2008, Ben Finney wrote:
> So, it's not correct for anyone but a release manager to decide
> “this bug is/is not release-critical, so I'll change the severity”;
> that is a perversion of the meaning of the severity field.
That's not quite true. See below.
> You can argue about wheth
Ben Finney writes:
> The decision of whether a bug is release-critical or not is for the
> release managers to make, using the various properties of the bug
> (including but *not* limited to its severity) as input to that
> decision. They can, in fact, make that decision apparent in the bug
> rep
Don Armstrong writes:
> On Thu, 25 Dec 2008, José Luis González wrote:
> > If a problem is RC, it should be marked as RC. If the BTS manages
> > pseudopackages, a bug in a pseudopackage that is RC should be
> > marked as RC in the BTS.
>
> The BTS has nothing to do with deciding whether particul
6 matches
Mail list logo