I think we should treat non-reproducible bugs, and "rejected" bugs
differently. A but that is "rejected," in my view, is one that makes no
sense, isn't worth the effort involved, or simply isn't going to be
done, for whatever reason. A bug that can't be reproduced might end up
in the "reject" pile, eventually, but there should be a fairly long
retention time. The bug report might wind up having information in it
that is valuable, if we do find out how to reproduce the but, at some
future time. I suspect this is going to be one of those where we have to
handle things on a case by case basis.
Ray
Dimitry Polivaev wrote:
Hi Eric and Dan,
Like Dan, I'd rather suggest to use the priority because that's what
it's meant for :-) So my suggestion would be something like:
- 5 - default value - someone needs to look into it and take a decision.
- >5 - important bug - no release before it's fixed.
- <5 - minor bug - release can happen without it being fixed.
I see that we still can mark less relevant bugs using lower priorities.
What about the bugs which seems not to be reproducible ? Should they
priority be lowered or could they be moved into Group "Rejected" ?
Dimitry
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freemind-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemind-developer
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freemind-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemind-developer
