Hi neutrinos, One of the areas I would like to work on during the Mitaka cycle is 'consistency' [1].
We've grown quite a bit during the last cycle and we need to make sure we are on the same page when it comes to code quality and reviews, and at the same time speeding up review velocity without compromising stability [2]. This is the reason why I started the 'Effective Neutron' guide [3], with the hope that we could start collating pills of wisdom that we identify during Neutron reviews, and capture lessons learned from regressions we may experience post merge. To this aim, I would invite people to start collectively add content to the guide. If you use the 'effective' tag [4], then it's easier to set them apart from the rest, for speedy review. If you are stumbling upon a bad pattern and you want to clean that up (like Cedric did in [5]), adding a tip at the same time of the patch is also ok, unless you pinky-swear you'll do that as follow up (the effective guide is available from Liberty, so backports may cause a conflict should you want to go back to Kilo). Cheers, Armando [1] http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n33 [2] http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n25 [3] http://docs.openstack.org/developer/neutron/devref/effective_neutron.html [4] https://review.openstack.org/#/q/project:openstack/neutron+topic:effective,n,z [5] https://review.openstack.org/#/c/230823/
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
