[openstack-dev] [Neutron] Core/Vendor code decomposition
armamig at gmail.com
Sat Dec 13 07:22:08 UTC 2014
On 12 December 2014 at 23:01, Yuriy Shovkoplias <yshovkoplias at mirantis.com>
> Dear neutron community,
> Can you please clarify couple points on the vendor code decomposition?
> - Assuming I would like to create the new driver now (Kilo development
> cycle) - is it already allowed (or mandatory) to follow the new process?
Yes. See  for more details.
> - Assuming the new process is already in place, are the following
> guidelines still applicable for the vendor integration code (not for vendor
> The following is a list of requirements for inclusion of code upstream:
> - Participation in Neutron meetings, IRC channels, and email lists.
> - A member of the plugin/driver team participating in code reviews of
> other upstream code.
I see no reason why you wouldn't follow those guidelines, as a general rule
of thumb. Having said that, some of the wording would need to be tweaked to
take into account of the new contribution model. Bear in mind, that I
started adding some developer documentation in , to give a practical
guide to the proposal. More to follow.
> On Thu, Dec 11, 2014 at 3:23 AM, Gary Kotton <gkotton at vmware.com> wrote:
>> On 12/11/14, 12:50 PM, "Ihar Hrachyshka" <ihrachys at redhat.com> wrote:
>> >-----BEGIN PGP SIGNED MESSAGE-----
>> >Hash: SHA512
>> >+100. I vote -1 there and would like to point out that we *must* keep
>> >history during the split, and split from u/s code base, not random
>> >repositories. If you don't know how to achieve this, ask oslo people,
>> >they did it plenty of times when graduating libraries from
>> >On 10/12/14 19:18, Cedric OLLIVIER wrote:
>> >> <https://review.openstack.org/#/c/140191/>
>> >> 2014-12-09 18:32 GMT+01:00 Armando M. <armamig at gmail.com
>> >> <mailto:armamig at gmail.com>>:
>> >> By the way, if Kyle can do it in his teeny tiny time that he has
>> >> left after his PTL duties, then anyone can do it! :)
>> >> https://review.openstack.org/#/c/140191/
>> This patch looses the recent hacking changes that we have made. This is a
>> slight example to try and highly the problem that we may incur as a
>> >> Fully cloning Dave Tucker's repository  and the outdated fork of
>> >> the ODL ML2 MechanismDriver included raises some questions (e.g.
>> >> ). I wish the next patch set removes some files. At least it
>> >> should take the mainstream work into account (e.g. ) .
>> >>  https://github.com/dave-tucker/odl-neutron-drivers 
>> >> https://review.openstack.org/#/c/113330/ 
>> >> https://review.openstack.org/#/c/96459/
>> >> _______________________________________________ OpenStack-dev
>> >> mailing list OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >-----BEGIN PGP SIGNATURE-----
>> >Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>> >-----END PGP SIGNATURE-----
>> >OpenStack-dev mailing list
>> >OpenStack-dev at lists.openstack.org
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev