cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Angus <>
Subject RE: 4.4 Feature Freeze
Date Tue, 04 Mar 2014 17:31:59 GMT
To stick my oar in,

I think that 3 days is too short a time for people to get round to doing meaningful testing,
particularly for those of us doing it on a purely voluntary basis.

Also I got the feeling that we were spinning up new RCs before it was clear that all issues
with the previous RC had been fixed and committed.

Maybe a -1 has to be accompanied by a Jira ticket marked as a blocker.  People should carry
on testing an RC after it's vote has been cancelled and adding -1s and Jira blockers tickets,
to avoid a new RC which is going to be -1ed immediately...  Once the blockers are cleared
we should be good to go for the next RC.


Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus

-----Original Message-----
From: Daan Hoogland []
Sent: 04 March 2014 15:55
To: dev
Subject: Re: 4.4 Feature Freeze

Animesh, You are doing a great job as guard on our present release and I don't recall features
slipping in either. instead those should now be added to the master branch. If Sebastien made
it sound that way it is probably because of something else that is bothering him.

However, Sebastien makes a very good point and I would go further. In my opinion we shouldn't
be talking about how many months we keep between releases. If I make a new feature I want
it scrutinized by all the guru's. Once they have nothing to nag about anymore it should be
in in less then a month. We are a long way from that, but having to plan a feature in advance
is never going to advance quality and instead will always be a constraint on it.

I could make the finger pointing point as well; At Schuberg Philis we are dedicating a lot
of effort to quality, both by tracking bug findings and by setting up an automated test environment.
I would prefer to spend this energy in making nice features for the next release. There is
seven of us now and I don't think we spend one seventh of our energy/time in new features
over the last period. The next release is containing a bunch of features already that won't
be stable from the get go anyway. let's make a good product before we make it greater.

So, can we find common ground on this issue? My take, rather one feature per release (each
week) with high quality and intensive testing then three features with divided attention to
the code involved. This is not a proposal, yet. Just an illustration of my emotions.

kind regards,

On Tue, Mar 4, 2014 at 1:45 PM, Sebastien Goasguen <> wrote:
> On Mar 3, 2014, at 8:18 PM, Animesh Chaturvedi <>
>>> -----Original Message-----
>>> From: Sebastien Goasguen []
>>> Sent: Sunday, March 02, 2014 10:13 AM
>>> To:
>>> Subject: Re: 4.4 Feature Freeze
>>> My take is that we are slipping on RC and re-voting because we are
>>> forcing code into the release.
>> [Animesh] That is not right, for 4.3 I had called out feature freeze date clearly
and do not recall new feature added.  IMHO the one challenge as community that we have which
has been raised earlier also is QA contribution is primarily coming from one organization.
Most other folks start taking the release for a spin only after RC2/RC3 or so and then we
see additional issues and more re-spins.  We really have to get all engaged in testing much
earlier in the cycle. Sudha used to call out for help on QA activity but in prior releases
I don't think she got much volunteers. We have huge technical debt and that is not going to
go away with pointing fingers. If a specific scenario is benefiting someone as a user/developer
of CloudStack and it turns out is not guarded with automation sufficiently and regresses in
a release shouldn't the person using it also take some responsibility for safeguarding it
with automation?
> Of course everyone is a stakeholder in making CloudStack a high quality software.
> I am not pointing fingers at anyone I am just expressing my perception of what is going
on. I have seen several things lately where it seems that we prefer to put half-baked features
in a major release rather than wait.
> Say we release every 6 months, since releases are far apart this puts stress on the developer
to put his feature "in" before feature freeze, perhaps sacrificing quality and testing. If
we were to release more often then the stress to "miss" a release would be alleviated.
> I'd rather see/know that developers don't rush their features because they know they
can see it in less than 4 months then see features being added to a release in fear of missing
a cycle.
> The issue of QA is another one. Personally I'd like to start testing a release branch
once code has stabilized and I'd prefer to see a RM lock down on the release before testing.
What we have seen (and I'd be happy to be wrong), is lots of code changes -a lot of times
without bug ids- even after an RC was out (even though this got corrected in the latest RC).
When there is so much churn on a release so close to an RC being cut it really is not conducive
to testing. Maybe the churn is not an issue, but imho I would like to see every commit being
with a bug ID and being a direct decision of the RM.
> -Sebastien

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure Support<>
offers the best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training<>
18th-19th February 2014, Brazil. Classroom<>
17th-23rd March 2014, Region A. Instructor led, On-line<>
24th-28th March 2014, Region B. Instructor led, On-line<>
16th-20th June 2014, Region A. Instructor led, On-line<>
23rd-27th June 2014, Region B. Instructor led, On-line<>

This email and any attachments to it may be confidential and are intended solely for the use
of the individual to whom it is addressed. Any views or opinions expressed are solely those
of the author and do not necessarily represent those of Shape Blue Ltd or related companies.
If you are not the intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender if you believe
you have received this email in error. Shape Blue Ltd is a company incorporated in England
& Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated
in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

View raw message