Open Stack

On 23 November 2016 at 16:42, 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
>

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-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/c99bfee4/attachment.html>