Open Stack

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 <harlowja at 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
>
> -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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161123/4565a83a/attachment.html>