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

Re: Release-critical Bugreport for July 30, 1999



On Fri, Jul 30, 1999 at 01:27:30PM +0200, Richard Braakman wrote:
> I'm replying to this because Joseph expresses a common misconception.
> 
> Joseph Carter wrote:
> > On Fri, Jul 30, 1999 at 12:15:07AM -0500, BugScan reporter wrote:
> > > Package: epic4-script-splitfire (main)
> > > Maintainer: Joseph Carter <knghtbrd@debian.org>
> > >   41920  EVIL EVIL on publics
> > 
> > While the bug is important (because what the script does is something it
> > really should not be doing), it should not be considered release critical.
> 
> I'm beginning to think the name "important" was a bad idea.  The sole
> difference between "important" and "normal" bugs is that the former
> are release-critical.  If the bug is not release-critical, it should
> not be severity "important".
> 
> If the script does something it really should not be doing, then that
> is indeed a bug.  We have a bug-tracking system for that!  "normal"
> severity does not mean "unimportant".  The two are not opposites.

It's marked important because there is no way to mark a bug as "seperate
this bug from the lot of the rest on the BTS page under my name" and
because it risks some form of data corruption.  This is of course never
acceptable and is most certainly release critical.

Because the chance for corruption is not as per default available, I'm
willing to release the package with a note outlining the risk someplace in
the documentation if I cannot fix it before release.  If I can find a way
to cause things to be mangled with the defaults (thinking about it now, I
suspect I can) I will simply not let the package be released with the bug.


> > It will be downgraded if neccessary, but I've got it flagged important so
> > I am reminded to harass the upstream maintainer about a fix now and then.
> > =>
> 
> This sounds like a normal, forwarded bug.
> 
> If it is not your opinion that this bug makes the package unsuitable for
> release, then please set it to normal severity.

If I cannot fix it and can't cause it to be worse than it appears to be at
first glance, I will downgrade the bug.  I think I've got a strategy for
fixing it now (depending on something which may have been added to the
epic pre2.004 series--or will be soon if it's not) but I do believe
important is the correct priority for the bug at the moment because of the
danger and lack of warning in the package.

It seems I will have to write some C to fix the problem.

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
<dark> Culus: Building a five-meter-high replica of the Empire State
       Building with paperclips is impressive.  Doing it blindfolded is
       eleet.

Attachment: pgpZV25ZmVY0a.pgp
Description: PGP signature


Reply to: