So in this definition, MAJOR and above must be fixed before a release is cut?
--Alex > -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Tuesday, March 5, 2013 11:03 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [QA][DISCUSS] Should we document formal release criteria? > > 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
