cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <kelven.y...@citrix.com>
Subject Re: [DISCUSS] ACS Release 4 month v/s 6 month
Date Tue, 23 Apr 2013 00:49:15 GMT
Given the remaining work to reshape CloudStack into a better architecture
to response other "Stacks" (i.e., OpenStack) at architecture level in
addition to feature development. I prefer a 6 month release cycle.

Kelven

On 4/22/13 4:47 PM, "Musayev, Ilya" <imusayev@webmd.net> wrote:

>Animesh
>
>I personally believe 4 months cycle is too rapid and we need more time to
>Qa and fix all issues.
>
>I'm finding issues constantly that automated tests missed.
>
>My opinion,  we should release a stable product when it's ready,
>hopefully following a 6 months cycle.
>
>Regards
>Ilya
>
>
>
>-------- Original message --------
>From: Animesh Chaturvedi <animesh.chaturvedi@citrix.com>
>Date:
>To: cloudstack-dev@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
>
>


Mime
View raw message