No subject

1. crashers
2. dataloss
3. regressions
4. something do not work as expected bugs
5. enhancements  

BTW: With time scheduled release cycle (monthly in your case) IMHO it is
difficult to triage bugs as blockers or critical anyway. 
I do not know if you are prepared to do chemspills, emergency releases or
stop the release channel if things go wrong big time...



>>  Maybe, but changing to NEW is quite complicated 
>> in your workflow, so mostly I leave them as UNCONFIRMED.
> Heh, what is complicated about it? Is the documentation unclear? IMHO,
> if you make sure that e bug is reproducible with the given information,
> you could move it to the state NEW.
> 

I thought so, but according to http://wiki.documentfoundation.org/BugTriage
there are three bold ANDs before you can change a status to NEW. 
Further more, an exclamation mark at the end of that paragraph 
(and the whole scary sentence before it) discouraged me to change anything
in the Status field at all.

Best regards.


--
View this message in context: http://nabble.documentfoundation.org/Re-3-5-3rc1-win32-debug-package-tp3984895p3988078.html
Sent from the Dev mailing list archive at Nabble.com.