> -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Tuesday, April 23, 2013 11:19 AM > To: dev@cloudstack.apache.org > Cc: cloudstack-...@incubator.apache.org > 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
