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.


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" ?


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Freemind-developer mailing list