Open Stack

On Mon, Dec 2, 2013 at 8:08 AM, Sandy Walsh <sandy.walsh at rackspace.com>wrote:

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

I think you misunderstand either my intent or the status of the library.

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.

Doug



>
>
> > Doug
> >
> >
> >
> >
> >     >
> >     > Doug
> >     >
> >     >
> >     >
> >     >
> >     >     -S
> >     >
> >     >     ________________________________________
> >     >     From: Eric Windisch [eric at cloudscaling.com
> >     <mailto:eric at cloudscaling.com>
> >     >     <mailto:eric at cloudscaling.com <mailto:eric at cloudscaling.com>>]
> >     >     Sent: Friday, November 29, 2013 2:47 PM
> >     >     To: OpenStack Development Mailing List (not for usage
> questions)
> >     >     Subject: Re: [openstack-dev] [oslo] maintenance policy for code
> >     >     graduating from the incubator
> >     >
> >     >     > Based on that, I would like to say that we do not add new
> >     features to
> >     >     > incubated code after it starts moving into a library, and
> >     only provide
> >     >     > "stable-like" bug fix support until integrated projects are
> >     moved
> >     >     over to
> >     >     > the graduated library (although even that is up for
> discussion).
> >     >     After all
> >     >     > integrated projects that use the code are using the library
> >     >     instead of the
> >     >     > incubator, we can delete the module(s) from the incubator.
> >     >
> >     >     +1
> >     >
> >     >     Although never formalized, this is how I had expected we would
> >     handle
> >     >     the graduation process. It is also how we have been responding
> to
> >     >     patches and blueprints offerings improvements and feature
> >     requests for
> >     >     oslo.messaging.
> >     >
> >     >     --
> >     >     Regards,
> >     >     Eric Windisch
> >     >
> >     >     _______________________________________________
> >     >     OpenStack-dev mailing list
> >     >     OpenStack-dev at lists.openstack.org
> >     <mailto:OpenStack-dev at lists.openstack.org>
> >     >     <mailto:OpenStack-dev at lists.openstack.org
> >     <mailto:OpenStack-dev at lists.openstack.org>>
> >     >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >     >
> >     >     _______________________________________________
> >     >     OpenStack-dev mailing list
> >     >     OpenStack-dev at lists.openstack.org
> >     <mailto:OpenStack-dev at lists.openstack.org>
> >     >     <mailto:OpenStack-dev at lists.openstack.org
> >     <mailto:OpenStack-dev at lists.openstack.org>>
> >     >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > OpenStack-dev mailing list
> >     > OpenStack-dev at lists.openstack.org
> >     <mailto:OpenStack-dev at lists.openstack.org>
> >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >     >
> >
> >     _______________________________________________
> >     OpenStack-dev mailing list
> >     OpenStack-dev at lists.openstack.org
> >     <mailto:OpenStack-dev at lists.openstack.org>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131202/453ac59b/attachment.html>