For bigger features (eg IPV6) and refactoring work, it is beneficial to test on the feature branches. If a feature which impacts several other areas gets checked in, we do not want the testing done so far invalid. This approach is taken to avoid risk in the last minute merges. - Quality is better as defects are isolated and gets fixed before check-in - Helps to keep master in stable condition without any interruption throughout development cycles
However this would not help to keep the cycles shorter. If it does, it would be marginal. - QA need to validate feature both on feature branch and on Master once check in happens. This takes more or less same amount of time. -----Original Message----- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, April 23, 2013 3:33 PM To: dev@cloudstack.apache.org Cc: cloudstack-...@incubator.apache.org Subject: RE: [DISCUSS] ACS Release 4 month v/s 6 month > -----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
