Once the final RC-1 list is finalized, from a review perspective, I think we should give priority to targeted bugs only.
It's hard to say what constitutes fair game or not for RC-1. Patches covering several modules which can potentially affect several features should generally be delayed, unless they fix use cases which are broken, such as the case of the issue gary found. Patches introducing new APIs, changing RPC interfaces, or adding capabilities to the 'common' modules should definitely be delayed, in my opinion. For plugin specific patches, code cleanup operations should be welcome (at least I wil favour them); also, I think that code refactoring operations or patches for adding support for specific Quantum extension should instead be evaluated on a case by case basis. Salvatore On 21 February 2013 19:18, Gary Kotton <gkot...@redhat.com> wrote: > Hi, > If possible can people please take a look at > https://review.openstack.org/#/c/22546/ - the problem here is with the > iptable rules (if the default rules are drop). > Thanks and have a good weekend > Gary > > > On 02/21/2013 08:15 PM, Sumit Naiksatam wrote: >> >> Thanks Dan. Are bugs related to code clean-up (removing unused code) >> fair game for RC1? >> >> Also, given that some of the bugs are not yet targeted for RC1 >> (basically the ones which don't have a milestone), should we be >> reviewing/merging those, or just wait for you to scrub/triage and tag? >> >> ~Sumit. >> >> On Thu, Feb 21, 2013 at 10:02 AM, Dan Wendlandt<d...@nicira.com> wrote: >>> >>> Ok team, >>> >>> Thanks for your patience dealing with the infrastructure issues. The G-3 >>> window will be closing in a few hours and the backlog seems to have >>> abated >>> (http://zuul.openstack.org/). We are now free to push bug fixes as long >>> as >>> they are targeted for RC1. >>> >>> Note: as RC1 gets closer, we need to start being more stringent that bug >>> fixes are really bugs, and not just small improvements that don't require >>> a >>> full blueprints. At this point, we are going to start being more >>> stringent >>> about what we allow to be targeted as a bug against RC1, and over the >>> weekend I will do a pass on all RC1 bugs booting out items that are not >>> actual fixes to broken functionality. The goal of items targeted against >>> RC1 should be to make sure existing capabilities are not broken, not to >>> add >>> new capabilities that were not there before. >>> >>> Also, please remember that we have three blueprints (two features) still >>> alive that need review and testing: >>> - multi-agent: >>> https://blueprints.launchpad.net/quantum/+spec/quantum-scheduler >>> - lbaas: >>> https://blueprints.launchpad.net/quantum/+spec/lbaas-namespace-agent and >>> https://blueprints.launchpad.net/quantum/+spec/lbaas-haproxy-driver >>> >>> At monday's meeting, we will make go/no-go decisions on these two >>> features, >>> as well as making sure any bugs we consider critical for RC1 have an >>> owner >>> assigned to them. >>> >>> We will also review the quantum client status, solidifying the date of >>> the >>> release that will correspond to grizzly functionality. >>> >>> Also, we will review our docs status, identify the big gaps we have and >>> who >>> is going to work on the associated documentation. Sub-teams, please make >>> sure that you have a handle on the doc bugs that need to be created in >>> your >>> area. >>> >>> Finally, a lot of you have been burning the midnight oil to make G-3 >>> happen, >>> so make sure you get a little relaxation in to recover in the next few >>> days >>> :) >>> >>> Dan >>> >>> >>> On Tue, Feb 19, 2013 at 3:13 PM, Dan Wendlandt<d...@nicira.com> wrote: >>>> >>>> Hi team, >>>> >>>> First couple important things from today's team meeting, particularly >>>> related to gating issues. >>>> >>>> - The gate is WAY behind and taking forever. A rash of pypi issues >>>> earlier this morning didn't help. PLEASE REFRAIN FROM SUBMITTING >>>> NON-BLOCKING BUGS TODAY OR TOMORROW. Basically, if its not actively >>>> preventing you from making progress on G-3, please hold off. If its >>>> truly >>>> important to have it fixed before G-3 milestone, go ahead an merge. >>>> >>>> - Due to the gate being behind, ttx is moving the deadline for requiring >>>> a >>>> Feature Freeze Exception by one day. I don't see a need to change any >>>> deadlines for Quantum though, so we're still operating in the mode that >>>> THINGS NEED TO BE MERGED BY TONIGHT TO GET INTO QUANTUM G-3. >>>> >>>> Finally, there are a lot of bugs targeted for G-3, most of which we need >>>> to bump out. There are three possibilities: >>>> - keep targeted for for G-3. Only for "critical" bugs that will impact >>>> someone's ability to test the G-3 milestone. >>>> - move to G-rc1. For any bug that just needs to be fixed before we >>>> release grizzly. >>>> - move to H-1. For any bug that isn't important enough or is too >>>> large/risky to be included in grizzly. >>>> >>>> I'll be updating bugs today at ttx's request. sub-team leads, please >>>> use >>>> the bug urls for your sub-project to make sure no bugs have been >>>> misclassified. >>>> >>>> Thanks, >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>> -- >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Dan Wendlandt >>>> Nicira, Inc: www.nicira.com >>>> twitter: danwendlandt >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> >>> >>> >>> -- >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Dan Wendlandt >>> Nicira, Inc: www.nicira.com >>> twitter: danwendlandt >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> -- >>> Mailing list: https://launchpad.net/~quantum-core >>> Post to : quantum-core@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~quantum-core >>> More help : https://help.launchpad.net/ListHelp >>> > > > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : quantum-core@lists.launchpad.net > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~quantum-core Post to : quantum-core@lists.launchpad.net Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
