Re: That need to close bugs?

["Justin Dugger" <jldugger@xxxxxxxxx>]

Hi,

> Sarah Hobbs:
> > So, do we leave them open, or close them as WONTFIX?  The users wont
> > really like it either way...
> >
> I'd close them. That way the user at least knows that there is a reason
> nobody is doing something about the bug.

> Plus, you need some indication anyway, for people who're looking for
> problems to fix, that this is not a good problem to start working on.
> So why not use the WONTFIX tag?

Firstly, I think it's a bit silly to be talking about WONTFIX when
it's not a valid status I can find in Launchpad.  Currently, WONTFIX
imports to Invalid I think. So I'll have to assume that you're talking
about adding a state WONTFIX separate from invalid.  Invalid seems
like a reasonable mark for things that are simply wrong, filed against
the wrong package

So who gets to mark things as WONTFIX in a volunteer driven team
projects?  And for people who're looking for problems to fix, WONTFIX
might improperly be interpreted by neophytes as a bug that is too hard
to fix, or that patches won't be accepted. You could change the
semantics to Ignored, but you're still left with the problem of who
gets to label a bug Ignored -- presumably at least the filer is
interested, or it would be marked insufficient.  And it suggesting
that marking a bug Ignored should cause other developers to ignore it
on the presumption that they must already have read and understood the
bug sounds flawed.

I took a moment to look at what currently gets marked WONTFIX in
Ubuntu (I have no idea how they got that way). Mostly it seems there's
two big categories:
* bugs against a specific release's version of a package (usually the
kernel), and
* bugs Ubuntu has a clear policy of ignoring (automatix, universe bugs
in early 2005, reports against a very beta kde4 package set, etc).

I think rather than Ignoring bugs for projects like Ubuntu a status of
"deferred to upstream" might be valid, if someone reports and links to
an upstream bug tracker (this appears similar to the current kde4
situation). Could it be that the drive of some developers to mark bugs
closed to ignore them reflects more on a package's diverse components
than the bugs themselves?  From what I can see, kdebase provides a
text editor, core io slaves, kdm, a window manager, a file / web
browser, and countless more.  That's quite a number of bugs to report
against a single package, and at a glance they seem only very loosely
related.  I imagine konquerer alone would be a handful to get on top
of.

One final comment -- that knowledge of existence of bugs causes
developers not to fix bugs seems fatalistic. I doubt repressing
memories of bug reports helps the cause much.

Justin Dugger