cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [QA][DISCUSS] Should we document formal release criteria?
Date Tue, 05 Mar 2013 19:11:51 GMT
So in this definition, MAJOR and above must be fixed before a release is cut?

--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