← Back to team overview

openerp-community team mailing list archive

Re: Please don't "won't fix" the baby with the bath water

 

On 01/20/2012 03:26 PM, "Lionel Sausin, de la part de l'équipe
informatique Numérigraphe" wrote:
> When v6.0 was released, the core team marked lots of bugs "invalid"
> or "won't fix" because they didn't intend to address them in v6.0, so
> that they don't "get in the way" before the release. I understand the
> need for a clean view of what bugs are blocking a release.
> But the way it was done was wrong. "Won't fix" means never:
> Launchpad hides the bug and we can't reopen it.

"Won't Fix" really means that the responsible team does not plan to fix
it or to make it a supported feature. It seems appropriate to me,
keeping such bugs open would be in fact be misleading, lead to questions
about their progress etc.
For bugs (or rather features) that look good but aren't planned for the
next release, we rather use "Confirmed" + "Wishlist" importance, as
explained in the bug management guide [1].

We have no problem publishing a new release even with a large number of
Wishlist bugs still open.


> Some of these bugs were real, and
> all the work that went into reporting, discussing and testing was
> essentially lost.

If they were marked "Won't Fix" that normally means they were not
considered real bugs, nor feature requests that we would consider
supporting in the foreseeable future.
Mistakes are of course possible, in which case you should not hesitate
to post a comment to request the reopening of the bug (or ask on this
list, for instance).

The work that went into the reporting of the bug is not lost at all, as
you can always find these bugs using the bugtracker's advanced search,
and/or request to reopen them.


> Now v6.1 will be released soon, and I can see another bug purge
> coming. In more and more reports the core team writes "ok we must do
> it, but it's complicated so we'll mark it won't fix anyway".

It should not be the case for 6.1 either, "Won't Fix" really means we
don't want to implement that feature. Nice-to-haves or
not-in-current-priorities bugs should be Confirmed+Wishlist if they are
considered good. Again, feel free to request the re-evaluation of any
such bug that you think was not properly qualified.
Of course this does not preclude divergence of opinion about specific
bugs, but you have no reason to be afraid of losing any bug report.


[1]
http://doc.openerp.com/v6.0/contribute/11_bug_tracker.html#bug-qualification


References