<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 2, 2013 at 8:08 AM, Sandy Walsh <span dir="ltr"><<a href="mailto:sandy.walsh@rackspace.com" target="_blank">sandy.walsh@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 12/01/2013 06:40 PM, Doug Hellmann wrote:<br>
><br>
><br>
><br>
> On Sat, Nov 30, 2013 at 3:52 PM, Sandy Walsh <<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a>>> wrote:<br>
><br>
><br>
><br>
>     On 11/29/2013 03:58 PM, Doug Hellmann wrote:<br>
>     ><br>
>     ><br>
>     ><br>
>     > On Fri, Nov 29, 2013 at 2:14 PM, Sandy Walsh<br>
>     <<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a> <mailto:<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a>><br>
</div>>     > <mailto:<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a><br>
<div><div class="h5">>     <mailto:<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a>>>> wrote:<br>
>     ><br>
>     >     So, as I mention in the branch, what about deployments that<br>
>     haven't<br>
>     >     transitioned to the library but would like to cherry pick this<br>
>     feature?<br>
>     ><br>
>     >     "after it starts moving into a library" can leave a very big gap<br>
>     >     when the functionality isn't available to users.<br>
>     ><br>
>     ><br>
>     > Are those deployments tracking trunk or a stable branch? Because IIUC,<br>
>     > we don't add features like this to stable branches for the main<br>
>     > components, either, and if they are tracking trunk then they will get<br>
>     > the new feature when it ships in a project that uses it. Are you<br>
>     > suggesting something in between?<br>
><br>
>     Tracking trunk. If the messaging branch has already landed in Nova, then<br>
>     this is a moot discussion. Otherwise we'll still need it in incubator.<br>
><br>
>     That said, consider if messaging wasn't in nova trunk. According to this<br>
>     policy the new functionality would have to wait until it was. And, as<br>
>     we've seen with messaging, that was a very long time. That doesn't seem<br>
>     reasonable.<br>
><br>
><br>
> The alternative is feature drift between the incubated version of rpc<br>
> and oslo.messaging, which makes the task of moving the other projects to<br>
> messaging even *harder*.<br>
><br>
> What I'm proposing seems like a standard deprecation/backport policy;<br>
> I'm not sure why you see the situation as different. Sandy, can you<br>
> elaborate on how you would expect to maintain feature parity between the<br>
> incubator and library while projects are in transition?<br>
<br>
</div></div>Deprecation usually assumes there is something in place to replace the<br>
old way.<br>
<br>
If I'm reading this correctly, you're proposing we stop adding to the<br>
existing library as soon as the new library has started?<br>
<br>
Shipping code always wins out. We can't stop development simply based on<br>
the promise that something new is on the way. Leaving the existing code<br>
to "bug fix only" status is far too limiting. In the case of messaging<br>
this would have meant an entire release cycle with no new features in<br>
oslo.rpc.<br>
<br>
Until the new code replaces the old, we have to suffer the pain of<br>
updating both codebases.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I think you misunderstand either my intent or the status of the library.</div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small">During Havana we accepted patches to the rpc code and developed oslo.messaging as a standalone library. Now that oslo.messaging has been released, it is "shipping code" and the rpc portion of the incubator can be deprecated during Icehouse.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
<br>
> Doug<br>
><br>
><br>
><br>
><br>
>     ><br>
>     > Doug<br>
>     ><br>
>     ><br>
>     ><br>
>     ><br>
>     >     -S<br>
>     ><br>
>     >     ________________________________________<br>
>     >     From: Eric Windisch [<a href="mailto:eric@cloudscaling.com">eric@cloudscaling.com</a><br>
>     <mailto:<a href="mailto:eric@cloudscaling.com">eric@cloudscaling.com</a>><br>
</div>>     >     <mailto:<a href="mailto:eric@cloudscaling.com">eric@cloudscaling.com</a> <mailto:<a href="mailto:eric@cloudscaling.com">eric@cloudscaling.com</a>>>]<br>
<div><div class="h5">>     >     Sent: Friday, November 29, 2013 2:47 PM<br>
>     >     To: OpenStack Development Mailing List (not for usage questions)<br>
>     >     Subject: Re: [openstack-dev] [oslo] maintenance policy for code<br>
>     >     graduating from the incubator<br>
>     ><br>
>     >     > Based on that, I would like to say that we do not add new<br>
>     features to<br>
>     >     > incubated code after it starts moving into a library, and<br>
>     only provide<br>
>     >     > "stable-like" bug fix support until integrated projects are<br>
>     moved<br>
>     >     over to<br>
>     >     > the graduated library (although even that is up for discussion).<br>
>     >     After all<br>
>     >     > integrated projects that use the code are using the library<br>
>     >     instead of the<br>
>     >     > incubator, we can delete the module(s) from the incubator.<br>
>     ><br>
>     >     +1<br>
>     ><br>
>     >     Although never formalized, this is how I had expected we would<br>
>     handle<br>
>     >     the graduation process. It is also how we have been responding to<br>
>     >     patches and blueprints offerings improvements and feature<br>
>     requests for<br>
>     >     oslo.messaging.<br>
>     ><br>
>     >     --<br>
>     >     Regards,<br>
>     >     Eric Windisch<br>
>     ><br>
>     >     _______________________________________________<br>
>     >     OpenStack-dev mailing list<br>
>     >     <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
</div></div>>     >     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<div class="im">>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>>><br>
>     >     <a 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>
>     ><br>
>     >     _______________________________________________<br>
>     >     OpenStack-dev mailing list<br>
>     >     <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
</div>>     >     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<div class="HOEnZb"><div class="h5">>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>>><br>
>     >     <a 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>
>     ><br>
>     ><br>
>     ><br>
>     ><br>
>     > _______________________________________________<br>
>     > OpenStack-dev mailing list<br>
>     > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>     > <a 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>
>     ><br>
><br>
>     _______________________________________________<br>
>     OpenStack-dev mailing list<br>
>     <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>     <a 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>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a 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>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a 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>
</div></div></blockquote></div><br></div></div>