On Tue, Mar 05, 2013 at 11:11:51AM -0800, Alex Huang wrote: > So in this definition, MAJOR and above must be fixed before a release is cut?
Personally, I've used the "no blockers and <5 critical with work arounds" as the criteria, using the definitions I offered. > > --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 > >
