Dear Ian, Don, On Wed, Mar 28 2018, Simon McVittie wrote: > On Wed, 28 Mar 2018 at 12:17:37 +0200, Andreas Tille wrote: >> I think "wontfix" is exactly the feature of the BTS that was invented >> to solve the problem I described. The bug is not closed and remains >> listed >> - so everybody is free to ignore that tag and close the bug. > > Is this how most people interpret wontfix? I'd usually interpreted it > as an indication of policy rather than priority: "I acknowledge that > this is a bug, but it isn't going to change, even if you provide a > patch". For instance, if there's a design flaw that people are now > relying on, such that correcting the design flaw would cause > regressions that are at least as bad as the design flaw itself, then > that's an ideal use for my interpretation of wontfix. > > In Bugzilla, WONTFIX and its cousins NOTABUG and NOTOURBUG are > resolutions, not tags (you use them by closing a bug as RESOLVED > WONTFIX instead of RESOLVED FIXED), which suggests that my > interpretation matches that of Bugzilla's designers; but perhaps the > wontfix tag in the Debian BTS was meant to mean something different? > > I would tend to use the help tag, not the wontfix tag, for bugs where > I don't intend to work on the bug myself but I'd consider applying a > patch (including porting to non-release architectures). I think it would be useful to have your opinions on this, as originators (at different points in history) of the current set of BTS tags. Perhaps we could improve the description of the tag on <https://www.debian.org/Bugs/Developer>. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature