On that note, we need to be careful *how* we merge features, otherwise it can be painful to revert.
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 >>> >> >
