Open Stack

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.


> 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
>