On 24 November 2016 at 05:27, Neil Jerram <n...@tigera.io> wrote: > But I think a periodic check for a Neutron/neutron-lib-using project (such > as networking-calico) would still be a decent way of catching such issues, > wouldn't it? >
It depends, and it would. There are many factors at play, as Kevin pointed out. > > > On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton <ke...@benton.pub> wrote: > >> The issue we had is different than breaking changes in neutron-lib. The >> issue we are running into now is bumps in the road when we are removing >> deprecated things from Neutron that other projects are still using even >> though they should be using the neutron-lib version instead. >> >> On Wed, Nov 23, 2016 at 5:42 PM, 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= >> build_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 >> >> -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/ >> source/contributing.rst >> [2] >> https://github.com/openstack/neutron-lib/blob/master/doc/ >> source/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.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 >> >> >> ____________________________________________________________ >> ______________ >> 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 >> > > __________________________________________________________________________ > 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