Open Stack

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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev