+1 for 6 month cycle till Automation is in place and current backlog of defects are reduced. Once we have automation we can switch to shorter cycles May be having release goals set to meet this criteria ( % of backlog to be cleared + %age of automation to be achieved) might help to reduce the cycles in 4.2.
1. Once IP Clearance is done, this may get to a little better to have community run automated tests on their own for check-ins. Helps to reduce the general QA timeline from current 2+ months to much shorter cycle with better quality code reaching QA. 2. Hope community can pick up a few more features for 4.2 compared to 4.1 so things can move a little faster. 3.Current 72 hour waiting period for code to get in to master is killing some time. Is there a way to reduce this timeline?? 4. Reviews got a lot better recently. This is helping definitely. Thanks /sudha -----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
