On 23 November 2016 at 16:42, Joshua Harlow <harlo...@fastmail.com> wrote:
> A suggestion would also to setup something like the following: > > https://wiki.openstack.org/wiki/Oslo#Periodic > > Get the users of neutron lib being tested against the latest neutron lib > (at least nightly) and seeing if they will be borked by a new neutron lib > merge... > > http://status.openstack.org/openstack-health/#/?groupKey=bui > ld_name&resolutionKey=hour&searchProject=-with-oslo > > Overall be careful with the APIs u expose and plan out how u will shift > users from the old API to the new API (without destroying the world during > that transition). > > My 3 cents :-P > I take the 3 cents, but we already do that :) http://status.openstack.org/openstack-health/#/?groupKey=build_name&resolutionKey=hour&searchProject=-with-neutron-lib-master > -Josh > > > Boden Russell wrote: > >> I would encourage anyone working on neutron-lib related changes to have >> a peek at the recently renovated contributing doc [1] if you haven't >> already. >> >> In particular the 'Phase 4: Consume' section [2] provides some tips on >> how we see this workflow playing out. >> >> Thanks >> >> [1] >> https://github.com/openstack/neutron-lib/blob/master/doc/sou >> rce/contributing.rst >> [2] >> https://github.com/openstack/neutron-lib/blob/master/doc/sou >> rce/contributing.rst#phase-4-consume >> >> >> On 11/23/16 12:39 PM, Armando M. wrote: >> >>> Hi neutrinos, >>> >>> In the last few hours a couple of changes landed [1,2] that caused a bit >>> of a jam in the neutron subproject gates, as they overlapped with >>> another change [3] having impact on the subprojects. >>> >>> This is why it is important to communicate during team meetings and/or >>> ML that patches with potential impact are in flight in our review >>> pipeline, so that we do our best to coordinate the merge process without >>> shooting ourselves in the foot. >>> >>> To bring this back to sanity, I issued a temporary revert [4], so that >>> [5] can land undisturbed. After that, a double revert will be applied, >>> once subprojects have had the opportunity to deal with the aftermath of >>> the other breaking change [1,2] (e.g. [6,7]). >>> >>> From now on, I'd strongly encourage people proposing/reviewing patches >>> with potential impact (any impact) to err on the side of caution, and >>> take the advised steps to ensure such situations don't happen in the >>> future. >>> >>> Thanks, >>> Armando >>> >>> [1] https://review.openstack.org/#/c/397704/ >>> [2] https://review.openstack.org/#/c/397037/ >>> [3] https://review.openstack.org/#/c/386845/ >>> [4] https://review.openstack.org/#/c/401377/ >>> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open >>> [6] https://review.openstack.org/#/c/401263/ >>> [7] https://review.openstack.org/#/c/401355/ >>> >>> >>> ____________________________________________________________ >>> ______________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
