On Mar 3, 2014, at 5:34 AM, Devdeep Singh <devdeep.si...@citrix.com> wrote:
> 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. > then it looks like you will have plenty of time to make these rock solid and well documented features for 4.5 > 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 > CLOUDSTACK-6181 > Root resize > Unassigned Nux Open Unresolved 27/Feb/14 > 27/Feb/14 > CLOUDSTACK-6161 > distributed routing and network ACL with OVS plug-in > Murali Reddy Murali Reddy Open Unresolved > 24/Feb/14 24/Feb/14 > CLOUDSTACK-6092 > Storage OverProvisioning as a Per Primary Basis > Saksham Srivastava Saksham Srivastava Open Unresolved > 13/Feb/14 20/Feb/14 > CLOUDSTACK-6144 > HA for guest VMs running Hyper-V > Unassigned Rajesh Battala Open Unresolved 20/Feb/14 > 20/Feb/14 > CLOUDSTACK-6143 > Storage Live-Migration support for Hyper-V > Unassigned Rajesh Battala Open Unresolved 20/Feb/14 > 20/Feb/14 > CLOUDSTACK-6142 > Zone Wide Primary Store in Hyper-V > Unassigned Rajesh Battala Open Unresolved 20/Feb/14 > 20/Feb/14 > CLOUDSTACK-6104 > PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment > Sateesh Chodapuneedi Sateesh Chodapuneedi Open > Unresolved 14/Feb/14 15/Feb/14 > CLOUDSTACK-6109 > Support of iSCSI as primary store in Hyper-V > Rajesh Battala Rajesh Battala Open Unresolved > 14/Feb/14 14/Feb/14 > CLOUDSTACK-6106 > Support of VPC in HyperV > Rajesh Battala Rajesh Battala Open Unresolved > 14/Feb/14 14/Feb/14 > CLOUDSTACK-6090 > Virtual Router Service Failure Alerting > Harikrishna Patnala Harikrishna Patnala Open > Unresolved 13/Feb/14 13/Feb/14 > CLOUDSTACK-6052 > List VM enhancement to support querying with multiple VM IDs > Koushik Das Koushik Das Open Unresolved 07/Feb/14 > 07/Feb/14 > CLOUDSTACK-5569 > enhance OVS plug-in to support region level VPC and guest networks that span > zones > Murali Reddy Murali Reddy Open Unresolved > 19/Dec/13 19/Dec/13 > CLOUDSTACK-5568 > introduce notion of guest network that spans multiple zones > Murali Reddy Murali Reddy Open Unresolved > 19/Dec/13 19/Dec/13 > CLOUDSTACK-5567 > enable VPC at region level > Murali Reddy Murali Reddy Open Unresolved > 19/Dec/13 19/Dec/13 > CLOUDSTACK-5398 > Cloudstack network-element plugin to orchestrate Juniper's switches > Unassigned Pradeep H Krishnamurthy Open Unresolved > 06/Dec/13 06/Dec/13 > > > > Cheers, > > Hugo > > On 28 feb. 2014, at 10:17, Prasanna Santhanam <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 >
