On Mon, Dec 2, 2013 at 8:08 AM, Sandy Walsh <sandy.wa...@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.wa...@rackspace.com > > <mailto:sandy.wa...@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.wa...@rackspace.com <mailto:sandy.wa...@rackspace.com> > > > <mailto:sandy.wa...@rackspace.com > > <mailto:sandy.wa...@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 [e...@cloudscaling.com > > <mailto:e...@cloudscaling.com> > > > <mailto:e...@cloudscaling.com <mailto:e...@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@lists.openstack.org > > <mailto:OpenStack-dev@lists.openstack.org> > > > <mailto:OpenStack-dev@lists.openstack.org > > <mailto:OpenStack-dev@lists.openstack.org>> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > _______________________________________________ > > > OpenStack-dev mailing list > > > OpenStack-dev@lists.openstack.org > > <mailto:OpenStack-dev@lists.openstack.org> > > > <mailto:OpenStack-dev@lists.openstack.org > > <mailto:OpenStack-dev@lists.openstack.org>> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > > > _______________________________________________ > > > OpenStack-dev mailing list > > > OpenStack-dev@lists.openstack.org > > <mailto:OpenStack-dev@lists.openstack.org> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > <mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
