incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [QA][DISCUSS] Should we document formal release criteria?
Date Tue, 05 Mar 2013 19:14:24 GMT
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.childers@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.childers@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
> 
> 

Mime
View raw message