<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
There is a proposal from Armando to clear this up:<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/148745/">https://review.openstack.org/#/c/148745/</a><br>
<br>
<div class="moz-cite-prefix">On 01/22/2015 03:53 PM, Sukhdev Kapur
wrote:<br>
</div>
<blockquote
cite="mid:CA+wZVHSF63m8kQtBc0h-8HjZUjAMvLyjGmwTBVZa4W3EAZhUEQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<p dir="ltr">Hi Ihar,</p>
<p dir="ltr">I have added this on the agenda for next neutron
core meeting to discuss.</p>
<p>This email gives an excellent context to the issue at hand.
Only one thing I would like to add is that the deadline for
stable/juno is only one week away - hence, it raises the
urgency to call for action. </p>
<p>Thanks</p>
<p>-Sukhdev</p>
<p><br>
</p>
<p dir="ltr"> <br>
On Jan 21, 2015 1:43 PM, "Ihar Hrachyshka" <<a
moz-do-not-send="true" href="mailto:ihrachys@redhat.com"
target="_blank">ihrachys@redhat.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> as per: <a moz-do-not-send="true"
href="https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst"
target="_blank">https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst</a>,
neutron is going to spin off vendor plugins into separate
trees outside of neutron core team control. This raises
several questions on how we are going to handle stable
branches that will still include plugin code for several
cycles.<br>
><br>
> 1) If a plugin is already spinned off and a patch is
applicable for stable branches, there are two cases:<br>
> - patch is not merged into vendor repo;<br>
> - patch is merged into the vendor repo.<br>
><br>
> My take is:<br>
> - if it's merged in the vendor repo, then we just
cherry-pick from there (it should just work if vendor repo was
created with the whole master history saved).<br>
> - if it's not merged into the repo, I would recommend the
author to propose and merge it there first. If there are any
justifiable issues with proposing it for vendor repo
inclusion, then we can consider stable-only merge.<br>
><br>
> 2) If a plugin is in the middle of spinning off and a
patch is applicable for stable branch, then there are two
options:<br>
> - require plugin to spin off first and then apply the
patch to vendor repo, or<br>
> - allow some types of patches to be merged into master
while vendors are working on spinning off the code.<br>
><br>
> Examples of those patches are:<br>
> - <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/147976/"
target="_blank">https://review.openstack.org/#/c/147976/</a><br>
> - <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/148369/"
target="_blank">https://review.openstack.org/#/c/148369/</a><br>
><br>
> Currently the patches above are blocked for master
inclusion assuming the spin off must take place first, and
then bugs should be fixed in vendor repo. At the same time, we
usually avoid backports unless the code is not in master
anymore, but that's not the case here. So the current approach
effectively blocks any bug fixes for plugins in stable
branches.<br>
><br>
> If we would be sure that a plugin is out of the tree till
Kilo, then it would indeed be a waste of time to review the
code for neutron/master since it would be guaranteed to be
released as a separate packagr e anyway. In that case, it
would be ok to forbid any patches for the plugin code till
its spin off from master, and the patch would go directly to
stable branches.<br>
><br>
> That said, it would potentially introduce regressions if
we consider upgrades from Juno to Kilo + vendor repo. We may
say that since the regression would be on vendor plugin side,
and neutron team does not have anything to do with spinned off
plugins, that would be fine for us.<br>
><br>
> But: we cannot guarantee that a plugin wil leave the
neutron tree this cycle. The spec explicitly gives permission
to stay in the tree till L-cycle, and in that case it will be
our responsibility to handle regressions in Kilo that we may
introduce by blocking master fixes.<br>
><br>
> I think we should try to set procedure that would avoid
potential regressions even if they will come from vendor
repos.<br>
><br>
> We allow fixes that are not applicable for final releases
for master if it's to be backported in stable branches. F.e.
see <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/127633/"
target="_blank">https://review.openstack.org/#/c/127633/</a>
that was merged into master while pecan migration should make
it useless for Kilo.<br>
><br>
> It's my belief plugin code bug fixes in stable branches
should be treated the same way.<br>
><br>
> That said, we should expect vendors to run third party CI
for stable branches if they want to see backports merged in.<br>
><br>
> ***<br>
> I think the correct approach here is:<br>
> - once a plugin is spinned off, consider it is a 'master'
for the code, and backport to stable branches directly from
there;<br>
> - before a plugin is spinned off, assume that it's not
going to be spinned off in Kilo, and hence allow bug fixes in
neutron/master (but not new features);<br>
> - once we get to L release that requires all vendor
plugin to go out, forbid any fixes for the code, assuming they
will either spin off or will be dropped anyway.<br>
> ***<br>
><br>
> The approach is pretty similar to how oslo project
handles new library spin-offs from oslo-incubator. Yes, there
is a difference here: in neutron, we loose any control on
spinned off repos. Though I don't feel it justifies
stable-only fixes while we can easily add value to vendor code
by asking people to consider fixing the bug there first. More
importantly, nothing should justify blocking bug fixing for
stable branches.<br>
><br>
> Thoughts?<br>
><br>
> /Ihar<br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage
questions)<br>
> Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>