Abhinandan, first one compromis-proposal, please. Can we not postpone but allow for this one feature (CLOUDSTACK-6161) this one time (4.4) to go in after feature freeze. If this is the only one and we don't consider this jurisprudence we could allow for it. @Hugo: say what?
On Mon, Mar 3, 2014 at 9:33 AM, Abhinandan Prateek <abhinandan.prat...@citrix.com> wrote: > 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)* > -- Daan
