I think there is no consensus on feature freeze date yet ? Daan, Shall we call for a vote on this ?
-abhi On 03/03/14 6:11 am, "Mike Tutkowski" <mike.tutkow...@solidfire.com> wrote: >I believe March 14th is Feature Freeze and, as such, when the 4.4 branch >is >cut. > > >On Sun, Mar 2, 2014 at 11:12 AM, Sebastien Goasguen ><run...@gmail.com>wrote: > >> >> On Feb 28, 2014, at 9:09 AM, Hugo Trippaers <h...@trippaers.nl> 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 >> 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 >> > <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 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 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 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 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 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 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 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 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 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 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. >> >> -sebastien >> >> >> > 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 >> >> >> > >> >> > > >-- >*Mike Tutkowski* >*Senior CloudStack Developer, SolidFire Inc.* >e: mike.tutkow...@solidfire.com >o: 303.746.7302 >Advancing the way the world uses the >cloud<http://solidfire.com/solution/overview/?video=play> >*(tm)*
