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
