cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <>
Subject Re: 4.4 Feature Freeze
Date Sun, 02 Mar 2014 18:12:32 GMT

On Feb 28, 2014, at 9:09 AM, Hugo Trippaers <> wrote:

> i’m all for being flexible, but i find a lot of the arguments used here debatable.
> “It causes developers to rush their development to meet the deadline." This will happen
anyway, every time we’ve extended the deadline we got new features coming in at the last
minute. Actually i’m under the impression that when we move the deadline people will actually
try to get more features in instead of working on stabilizing existing features.
> “We can’t deliver features on the roadmap.” There is validity to this point, but
on the other hand we already know the entire release schedule way ahead, this feature freeze
date should not come as a surprise. But as i mentioned in an earlier mail, lets have this
discussion. Post which features might not make it into the release so we can have a discussion
if we should slip the release date to get this feature in. I think we all now that there are
commercial parties working with this software to build releases and have customers demanding
features, but if we don’t discuss that on list it’s hard for us to take it into account.
> “Feature freeze wasn’t called” True, i wasn’t even aware that this was a requirement.
We should add this to the procedure here
so release managers know this is expected of them. It should not impact the dates as the dates
are already fixed by the release schedule (every 4 months)
> I’m still -1 on extending the feature freeze. I would rather extend the test/stability
phase to we have some more time to fix issues before we get into the RC spinning. 
> This is the list of current features targeted for 4.4 according to our Jira. Which features
would be impacted if we don’t move the feature freeze?
> Project: CloudStack
> Type: New Feature
> Fix Version: 4.4.0
> Resolution: Unresolved
> Sorted by: Updated descending
> 1–15 of 15 as at: 28/Feb/14 15:07
> T	Key	Summary	Assignee	Reporter	P	Status	Resolution	Created	Updated	Due
> <newfeature.png>	CLOUDSTACK-6181	
> Root resize
> Unassigned	Nux	<major.png>	<open.png> Open	Unresolved	27/Feb/14	27/Feb/14
> <newfeature.png>	CLOUDSTACK-6161	
> distributed routing and network ACL with OVS plug-in
> Murali Reddy	Murali Reddy	<major.png>	<open.png> Open	Unresolved	24/Feb/14
> <newfeature.png>	CLOUDSTACK-6092	
> Storage OverProvisioning as a Per Primary Basis
> Saksham Srivastava	Saksham Srivastava	<major.png>	<open.png> Open	Unresolved
13/Feb/14	20/Feb/14	 
> <newfeature.png>	CLOUDSTACK-6144	
> HA for guest VMs running Hyper-V
> Unassigned	Rajesh Battala	<major.png>	<open.png> Open	Unresolved	20/Feb/14
> <newfeature.png>	CLOUDSTACK-6143	
> Storage Live-Migration support for Hyper-V
> Unassigned	Rajesh Battala	<major.png>	<open.png> Open	Unresolved	20/Feb/14
> <newfeature.png>	CLOUDSTACK-6142	
> Zone Wide Primary Store in Hyper-V
> Unassigned	Rajesh Battala	<major.png>	<open.png> Open	Unresolved	20/Feb/14
> <newfeature.png>	CLOUDSTACK-6104	
> PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
> Sateesh Chodapuneedi	Sateesh Chodapuneedi	<major.png>	<open.png> Open	Unresolved
14/Feb/14	15/Feb/14	 
> <newfeature.png>	CLOUDSTACK-6109	
> Support of iSCSI as primary store in Hyper-V
> Rajesh Battala	Rajesh Battala	<major.png>	<open.png> Open	Unresolved	14/Feb/14
> <newfeature.png>	CLOUDSTACK-6106	
> Support of VPC in HyperV
> Rajesh Battala	Rajesh Battala	<major.png>	<open.png> Open	Unresolved	14/Feb/14
> <newfeature.png>	CLOUDSTACK-6090	
> Virtual Router Service Failure Alerting
> Harikrishna Patnala	Harikrishna Patnala	<major.png>	<open.png> Open	Unresolved
13/Feb/14	13/Feb/14	 
> <newfeature.png>	CLOUDSTACK-6052	
> List VM enhancement to support querying with multiple VM IDs
> Koushik Das	Koushik Das	<major.png>	<open.png> Open	Unresolved	07/Feb/14
> <newfeature.png>	CLOUDSTACK-5569	
> enhance OVS plug-in to support region level VPC and guest networks that span zones
> Murali Reddy	Murali Reddy	<major.png>	<open.png> Open	Unresolved	19/Dec/13
> <newfeature.png>	CLOUDSTACK-5568	
> introduce notion of guest network that spans multiple zones
> Murali Reddy	Murali Reddy	<major.png>	<open.png> Open	Unresolved	19/Dec/13
> <newfeature.png>	CLOUDSTACK-5567	
> enable VPC at region level
> Murali Reddy	Murali Reddy	<major.png>	<open.png> Open	Unresolved	19/Dec/13
> <newfeature.png>	CLOUDSTACK-5398	
> Cloudstack network-element plugin to orchestrate Juniper's switches
> Unassigned	Pradeep H Krishnamurthy	<major.png>	<open.png> Open	Unresolved
06/Dec/13	06/Dec/13	 

Hugo as RM for 4.4 I would like support you in being strict on this.

First if a feature is not listed in JIRA right now, then it does not exist and is not planned
for 4.4
These features should be in topic branches and merges should be called, if one of those gets
merged without a MERGE request then we should revert. When a MERGE is called the person calling
the merge needs to explain the testing done.

Postponing always encourages more postponing, we need to get off the habit of rushing code
in and then fixing that code in the multiple RC votes.

My take is that we are slipping on RC and re-voting because we are forcing code into the release.

I did not check if the 4.4 branch exists already but I would be in favor of locking that branch
now with you being the only one to commit to it.


> Cheers,
> Hugo
> On 28 feb. 2014, at 10:17, Prasanna Santhanam <> wrote:
>> On Fri, Feb 28, 2014 at 07:26:10AM +0000, Ram Ganesh wrote:
>>> Yes. I can only agree with you on this.  When we come up with dates
>>> we have to be cognizant about slips in prior releases (we had 6 RC
>>> re-spins and counting....) which would have had impact which is the
>>> case now.  We have to be bit flexible with our dates. 
>> But you do agree that the re-spins uncovered bugs/issues that needed
>> to be fixed? Is it perhaps a mismatch in when the artifacts start
>> getting tested by the users+devs as opposed to when company-x might be
>> satisfied with their testing? More than 90% of the re-spins are
>> bugs/issues uncovered by users who needed RC candidates and weren't
>> testing artifacts on a daily basis (I could be wrong here). I don't
>> think someone with a large test engineering team would wait for the
>> RCs to get rolling. May be if we addressed that mismatch in timing we
>> could have smaller RC phases. Something like a soft-freeze and a
>> hard-freeze.  
>> post soft-freeze : users+devs do a daily test (mostly manually for
>> features they care about)
>> post hard-freeze : everyone only looks at a daily automated test
>> report and if all looks good, we release?
>> -- 
>> Prasanna.,
>> ------------------------
>> Powered by

View raw message