Daan, Since you are the 4.4 RM we will respect your decision. -abhi
On 03/03/14 2:11 pm, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >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
