Bugging questions

[Brad Bollenbach]

On Mon, 2006-05-01 at 15:28 +1200, Matthew Paul Thomas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Apr 30, 2006, at 12:30 AM, Christian Robottom Reis wrote:
> >
> > On Sat, Apr 29, 2006 at 08:32:30PM +1200, Matthew Paul Thomas wrote:
> > ...
> >> 1.  A simple bug about Thunderbird in Ubuntu also occurs upstream,
> >>     it's not important enough for the distro team to fix specially,
> >>     and it's reported upstream. Mozilla Thunderbird status: automatic
> >>     (from a bug watch). Ubuntu status: Not For Us.
> >>
> >> 2.  A bug about Rosetta language charts being unusable in Ubuntu's
> >>     emacs-w3m turns out to be a layout bug in w3m. Nobody is going to
> >>     fix it specially for Ubuntu, and w3m upstream doesn't even *have*
> >>     a bug tracker, but we can work around it in Rosetta. Rosetta
> >>     status: Confirmed. w3m status: not recorded. Ubuntu w3m status:
> >>     Not For Us.
> >>
> >> 3.  It's three weeks before the release of Edgy. A bug reported about
> >>     the Ubuntu Installer was initially accepted for fixing in Edgy,
> >>     but now it's too late, so it's deferred. Ubuntu ubuntu-installer
> >>     status: Confirmed. Ubuntu Edgy ubuntu-installer status: Not For
> >>     Us.
> >>
> >> 4.  FooConf upstream receives a report of a platform-specific bug in
> >>     an unofficial BeOS package. "Sorry", say the maintainers, "that
> >>     might be a real bug, but we're not going to include special code
> >>     to support BeOS. Talk to the porters." BeOS-Ports fooconf status:
> >>     Confirmed. FooConf status: Not For Us.
> >>
> >> 5.  Firefox (imagining for the moment that Mozilla uses Malone)
> >>     doesn't have proper title bar icons in Windows 95/98. It's a
> >>     valid bug with a known fix, but Mozilla's never going to fix it,
> >>     and there are no other packagers. Firefox status: Not For Us. No
> >>     other statuses.
> >>
> >> "Won't Fix Here", "Disavowed", and "Not For Us" are the only
> >> suggestions made so far that work for all these examples. (All those
> >> mentioning "upstream" fail examples 3, 4, and 5; all those suggesting
> >
> > I think that's because examples 3, 4 and 5 describe something 
> > different from 1 and 2. Don't you think that distinction is worth 
> > capturing?
> > ...
> 
> They're all cases where the bug should show up by default for reporters 
> (so they don't report duplicates), but should not show up by default 
> for developers (so they're not distracted by bugs they've decided not 
> to fix). And they're all cases where it's best not to use "Rejected" 
> ("well, f___ you too") or its successor "Not a Bug" ("oh yes it is!"). 
> What distinction are you referring to?

The only distinction I see worth capturing is with #3.

#3 is a release manager's decision, for a bug we do want to fix, just
not in a particular release. It's confusing if 4/5 times NFU means "we
don't care enough to fix this bug, but maybe somebody else will", but
1/5 times it means "this is a bug we want to fix, but not in release
Foo".

This is why splitting Rejected into Wontfix and Invalid has been
suggested--all the above examples would be Wontfix. Wontfix is more
accurate but less precise and still has that "f___ you too" feel of
Rejected.

There are various reasons why developers might say "No" to an otherwise
reasonable bug report, and other than for release management, "No"
requires an explanation to diffuse the offence. What about "Wontfix"
with an explanation required (the normal change comment), but optional
on distrorelease tasks?

Brad