cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Animesh Chaturvedi <>
Subject RE: [DISCUSS] ACS Release 4 month v/s 6 month
Date Tue, 23 Apr 2013 22:33:04 GMT

> -----Original Message-----
> From: Chip Childers []
> Sent: Tuesday, April 23, 2013 11:19 AM
> To:
> Cc:
> Subject: Re: [DISCUSS] ACS Release 4 month v/s 6 month
> On Tue, Apr 23, 2013 at 10:55:50AM -0700, Will Chan wrote:
> > Again, I am not disputing that more features will make it in given Dave's
> argument.  In fact, I'm not really that keen on using the fixed cost of release
> mgmt. for the reason of the move as well.   Heck, I'm not even sure a 6
> month cycle would fix any of the issues that have already been outlined but
> it'd be nice to try.  However, I do know a couple of things:
> >
> > 1. We all want CS releases to be of certain quality.  It needs to work and
> upgrades need to work.
> +1 - Absolutely
> > 2. ACS still relies too heavily on manual testing and most of it unfortunately
> comes from 1 company.  We cannot be dependent on another company's
> schedule to ensure ACS has gone through enough proper testing to achieve
> (1).
> Also agreed, but this only relates to release schedule for regression and
> upgrade testing really.  Feature testing is something that should / can be
> handled prior to a merge in my mind.
[Animesh>] If feature testing could mostly be completed in feature branch that would be
ideal. However given our limited automation,  manual QA testing on feature branch is logistically
challenging when a QA person is testing multiple features. Sudha/ folks doing primarily QA
function can you provide your feedback? 

> > 3. Most importantly, the extra 2 months will give QA more time, give
> features more time to settle in, and more automated tests to be written for
> existing features as well.  I agree with Dave that more feature will come in.
> So what?  If they are not of good enough quality, we don't release it as part
> of the ACS release.  However, that extra 2 month will give earlier written
> features more time to be potentially tested and used by people so that we
> fix the most egregious bugs before we ship it.  It will also better
> accommodate people's schedule so they can fix bugs for their features.
> >
> How do you see the release schedule laying out with multiple releases over
> the course of time?  What overlaps exist?
> We *really should not* plan on blocking new features from coming into
> master as they are completed.  That's just an inhibitor to progress.
> Given that assumption, I fail to see how the we would be doing anything
> *but* increasing the overall change size by increasing the time between
> feature releases.  That leads to increased "cost of release".
> > Personally, so far, I feel 4 months seems a bit rushed.
> >
> > Will

View raw message