cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Mehta <>
Subject Re: [DISCUSS] ACS Release 4 month v/s 6 month
Date Tue, 23 Apr 2013 05:32:40 GMT
David - You have some compelling logic :)
Given the debate about 4 month to 6 month, lets make an educated decision

First - Lets hear from the "release managers" as to what they have to say
about the last 2 releases. What went well and what didn't. Chip - ?
Second - If we plan to do a 6 month release what would be the timelines in
place ? Like time allocated for what features going in the release,
feature discussion and coding, bug fixing, testing, documentation etc. If
I get a rough idea on that for the 6 month release it would help me
understand the differences.

At this point I would still +1 a 6 month release because it gives me good
time to discuss, code, unit test and bake my feature. From my experience
at this point this definitely makes more sense.
We can revisit the time line after a couple releases as we all become more
accustomed with the processes in place.


On 23/04/13 8:21 AM, "David Nalley" <> wrote:

>On Mon, Apr 22, 2013 at 5:19 PM, Animesh Chaturvedi
><> wrote:
>> 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
>> If I missed out  any important point please feel free to bring into the
>> 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]
>Hi Animesh:
>I thought I would add a few comments. To the folks reading - I
>apologize for the length. If you haven't started yet, you may want to
>get some coffee/tea. You've been warned. :)
>I think there are two concerns people think about when talking about
>changing the length of the release cycle.
>The first concern is workload. Generating a release has a certain
>fixed amount of overhead. Writing release notes, running votes, and a
>key part of the discussion currently is the QA cycle. Currently a
>large portion of our QA cycle is manual testing, which means we need
>lots of fingers on keyboards to get it done.
>The other concern is quality. We always want to try and put our best
>foot forward, and minimize bugs, yet the very act of developing
>software, and especially developing new features, introduces bugs.
>Before I start telling you my reasoning, I want to lay out something
>that only hit me tonight. We've talked about how extending the release
>cycle only extends the length of development. We've talked about
>keeping the length of the development period (e.g. pre-code freeze)
>the same, and essentially only extending the amount of time for QA.
>That works for the first release after a move from 4 to 6 months. It
>falls apart there after though. The problem is that at code freeze we
>branch. Master immediately becomes open for future feature
>development, and you've just extended it by an additional 2 months,
>because your cycle is that much longer.
>I personally don't think that either concern is addressed well by
>lengthening the cycle. Let me explain why
>On the quality front - the immediate threat to quality is instability
>inserted by additional development/new features/improvements. By
>increasing the length of time for that disruption to occur, we get
>more of it, as people will continue adding things that might have been
>deferred to a later release. We have code merged that, realistically,
>we won't know if it works properly until QA has gone in and verified
>it, perhaps months later. The more paths changed in a given release,
>the greater the propensity for failure.

Agreed, but merely changing the time duration doesn't really solve the
problem. More automation, having a staging branch would still do a better
But with the current context what you say makes sense.

>On the overhead front - the overhead of writing release notes and
>generating releases goes down. In addition the 'basic' testing that QA
>does now is additional overhead in each cycle as well. What isn't
>overhead though is testing for new features. Because effectively
>longer cycles mean greater amount of codebase change, more features,
>etc. The actual testing in a given cycle must also increase.
>If we were really focused on absolute best quality we could deliver
>with our current tooling, I believe the easiest would be to make our
>release cycle the length of a single feature development period + the
>QA cycle (e.g. shortening the release cycle.)
>Is there a right or wrong answer? There shouldn't be. Our software
>should be deliverable at any point in the development cycle we choose.
>4 months or 6 months would not be a quality, or QA workload issue. We
>would have automated test suites written for 80+% of our testing and
>we would run comprehensive tests against propose merges to guarantee
>that an incoming features both works as intended, and doesn't harm the
>rest of the platform in the process. We'd make release cycle decisions
>based upon the same kind of preferences that make us choose a monkey
>mascot over a polar bear mascot.
>That sadly isn't where we are today, but I do think it illuminates a
>clear path of where we need to go. (more automated testing)
>So where do I fall on 4 months versus 6 months?
>I think we should stay the 4 month course. Heres why:
>* We set the 4-month release cycle expectation already. In theory
>we've been through 2 releases, but really only 4.1 - 4.0 was dominated
>by getting into the incubator, getting releases okayed legally, etc.
>It took us 7 months to release. I am loathe to change something we
>only recently set, and have only been through once. I am also worried
>about the signal that such rapid contrary decision changes would send
>to our users.
>* I am worried about the impact to quality of our releases. Greater
>introduction of features means an increased threat to stability. It
>may not impact us in the 4.2 cycle, but without massive automated QA
>it will impact us going forward in the 4.3 and later time frames.

Great point and I agree this can definitely be an issue.

>If you've made it thus far, I hope your tea/coffee was enjoyable.
>Thanks for reading. :)

Had to take 2 :).


View raw message