I was looking into adding support for iSCSI (CLOUDSTACK-6109) and HA of guest 
vms (CLOUDSTACK-6144) for hyper-v. I don't think I'll be able to finish it by 
14th.



Regards,

Devdeep


From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Friday, February 28, 2014 7:40 PM
To: <dev@cloudstack.apache.org>
Subject: Re: 4.4 Feature Freeze

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 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases 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?

ASF JIRA
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
[New Feature]      CLOUDSTACK-6181
Root resize
Unassigned    Nux     [Major]         [Open]  Open          Unresolved      
27/Feb/14        27/Feb/14
[New Feature]      CLOUDSTACK-6161
distributed routing and network ACL with OVS plug-in
Murali Reddy            Murali Reddy  [Major]         [Open]  Open          
Unresolved      24/Feb/14        24/Feb/14
[New Feature]      CLOUDSTACK-6092
Storage OverProvisioning as a Per Primary Basis
Saksham Srivastava   Saksham Srivastava    [Major]         [Open]  Open         
 Unresolved      13/Feb/14        20/Feb/14
[New Feature]      CLOUDSTACK-6144
HA for guest VMs running Hyper-V
Unassigned    Rajesh Battala [Major]         [Open]  Open          Unresolved   
   20/Feb/14        20/Feb/14
[New Feature]      CLOUDSTACK-6143
Storage Live-Migration support for Hyper-V
Unassigned    Rajesh Battala [Major]         [Open]  Open          Unresolved   
   20/Feb/14        20/Feb/14
[New Feature]      CLOUDSTACK-6142
Zone Wide Primary Store in Hyper-V
Unassigned    Rajesh Battala [Major]         [Open]  Open          Unresolved   
   20/Feb/14        20/Feb/14
[New Feature]      CLOUDSTACK-6104
PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
Sateesh Chodapuneedi          Sateesh Chodapuneedi           [Major]         
[Open]  Open          Unresolved      14/Feb/14          15/Feb/14
[New Feature]      CLOUDSTACK-6109
Support of iSCSI as primary store in Hyper-V
Rajesh Battala           Rajesh Battala [Major]         [Open]  Open          
Unresolved      14/Feb/14        14/Feb/14
[New Feature]      CLOUDSTACK-6106
Support of VPC in HyperV
Rajesh Battala           Rajesh Battala [Major]         [Open]  Open          
Unresolved      14/Feb/14        14/Feb/14
[New Feature]      CLOUDSTACK-6090
Virtual Router Service Failure Alerting
Harikrishna Patnala   Harikrishna Patnala     [Major]         [Open]  Open      
    Unresolved      13/Feb/14        13/Feb/14
[New Feature]      CLOUDSTACK-6052
List VM enhancement to support querying with multiple VM IDs
Koushik Das  Koushik Das   [Major]         [Open]  Open          Unresolved     
 07/Feb/14        07/Feb/14
[New Feature]      CLOUDSTACK-5569
enhance OVS plug-in to support region level VPC and guest networks that span 
zones
Murali Reddy            Murali Reddy  [Major]         [Open]  Open          
Unresolved      19/Dec/13        19/Dec/13
[New Feature]      CLOUDSTACK-5568
introduce notion of guest network that spans multiple zones
Murali Reddy            Murali Reddy  [Major]         [Open]  Open          
Unresolved      19/Dec/13        19/Dec/13
[New Feature]      CLOUDSTACK-5567
enable VPC at region level
Murali Reddy            Murali Reddy  [Major]         [Open]  Open          
Unresolved      19/Dec/13        19/Dec/13
[New Feature]      CLOUDSTACK-5398
Cloudstack network-element plugin to orchestrate Juniper's switches
Unassigned    Pradeep H Krishnamurthy      [Major]         [Open]  Open         
 Unresolved      06/Dec/13        06/Dec/13



Cheers,

Hugo

On 28 feb. 2014, at 10:17, Prasanna Santhanam 
<t...@apache.org<mailto:t...@apache.org>> 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 BigRock.com<http://BigRock.com>

Reply via email to