On Tue, Mar 05, 2013 at 01:39:50PM -0500, David Nalley wrote: > On Tue, Mar 5, 2013 at 1:32 PM, Chip Childers <chip.child...@sungard.com> > wrote: > > Hi all, > > > > Some IRC discussion triggered this thought: > > > > Should we document our formal release criteria? By that, I mean - > > should we document the criteria that we use to claim that we are in a > > position to cut an actual Release Candidate for voting? > > > > YES!!! > > > > I realized that I've had my own view sitting in my head, but obviously > > that means that nobody else knows it! > > > > Thoughts about what our criteria should be? > > > > Here's what's in my head: > > > > No Blocker Bugs outstanding > > No Critical Bugs outstanding (unless there is a work-around, and only < > > 5 like that) > > So define for me what is a blocker and critical. > I have my own internal definition, but if we have a standard that says > 'no blocker and critical bugs' then we are just doing blind queries > against Jira and maybe even changing the value on a bug so we can be > releasable.
Here's how I've defined them in other environments. This may not work for us, but it's a starting point: Blocker - Bugs which result in data corruption or inaccuracies in the data produced or manipulated by the product under test. Discrepancies compromising the functionality of the product under test. No workaround is available. Any security vulnerability. Critical - Commonly used elements of the product under test cause errors which result in the product under test to stop functioning as designed. Users are very likely to encounter the error. A workaround may be available. And just to be complete: Major - Errors that does not affect critical functions. Internal errors that will not be seen by the user. A work around may be available. Minor - Cosmetic errors (including grammar and spelling). Trivial - Silly things that really don't matter all that much
