+1 for 6 months, leave buffer for testing and bug fixing -Mice
-----Original Message----- From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com] Sent: Tuesday, April 23, 2013 12:36 PM To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org Subject: RE: [DISCUSS] ACS Release 4 month v/s 6 month + 1 for 6 months From documentation perspective, it gives the doc contributors ample time to play around with the features; accommodate all the review cycles (unit tests, technical, and editorial if that applies); fix more number of defects. -----Original Message----- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, April 23, 2013 4:38 AM To: dev@cloudstack.apache.org; cloudstack-...@incubator.apache.org Subject: RE: [DISCUSS] ACS Release 4 month v/s 6 month > -----Original Message----- > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > Sent: Monday, April 22, 2013 2:20 PM > To: cloudstack-...@incubator.apache.org > Subject: [DISCUSS] ACS Release 4 month v/s 6 month > > Folks > > We started discussing 4 month v/s 6 month release cycle in a another > thread [1]. Since the subject of that thread was different, community > may not have participated in this important discussion fully. I am > are bringing this discussion to its own thread. Here is the summary so > far please refer to [1] for more details. > > Summary of discussion: > - Animesh pointed out the technical debt that we have accumulated so > far needs extra time to resolve > - David, Chip favor shorter release cycle of 4 month and keeping > master always stable and in good quality and enhancing automation as a > solution to reduce QA manual effort. A focused defect fixing activity > may be needed to reduce technical debt > - Will brought up several points in the discussion: He called out > heavy dependence on manual QA for a release and pointed out that > manual QA may not be always available to match up ACS release > schedule. Release overhead for 4 month release is still high and > suggest that moving to 6 month will save on release overhead and that time > can be used for strengthening automation. > - Joe agrees partly in release overhead being significant for major > release > > If I missed out any important point please feel free to bring into the > thread. > > There were some other discussion in [1] on release planning conference > and chip's clarification on time based v/s feature based releases but > we will not discuss those in this thread. Community has agreed to > time-based release already. > > [1] http://markmail.org/thread/6suq2fhltdvgvcxd [Animesh>] Please provide your input.
