Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Mon, 2013-12-02 at 11:00 -0500, Doug Hellmann wrote: I have updated the Oslo wiki page with these details and would appreciate feedback on the wording used there. https://wiki.openstack.org/wiki/Oslo#Graduation Thanks Doug, that sounds perfect to me. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On 29/11/13 13:47 -0500, Eric Windisch wrote: 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. +1 FF -- @flaper87 Flavio Percoco pgpq0wWsoLCQL.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Fri, Nov 29 2013, Doug Hellmann wrote: Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. +1 I think it's a good idea. It'll push people forward migrating to the split library if they want the new features. -- Julien Danjou -- Free Software hacker - independent consultant -- http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
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. 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
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On 11/29/2013 01:39 PM, Doug Hellmann wrote: We have a review up (https://review.openstack.org/#/c/58297/) to add some features to the notification system in the oslo incubator. THe notification system is being moved into oslo.messaging, and so we have the question of whether to accept the patch to the incubated version, move it to oslo.messaging, or carry it in both. As I say in the review, from a practical standpoint I think we can't really support continued development in both places. Given the number of times the topic of just make everything a library has come up, I would prefer that we focus our energy on completing the transition for a given module or library once it the process starts. We also need to avoid feature drift, and provide a clear incentive for projects to update to the new library. 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. Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. +1 in general. You may want to make after it starts moving into a library more specific, though. One approach could be to reflect this status in the MAINTAINERS file. Right now there is a status field for each module in the incubator: S: Status, one of the following: Maintained: Has an active maintainer Orphan: No current maintainer, feel free to step up! Obsolete:Replaced by newer code, or a dead end, or out-dated It seems that the types of code we're talking about should just be marked as Obsolete. Obsolete code should only get stable-like bug fixes. That would mean marking 'rpc' and 'notifier' as Obsolete (currently listed as Maintained). I think that is accurate, though. https://review.openstack.org/59367 -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Mon, Dec 2, 2013 at 8:08 AM, Sandy Walsh sandy.wa...@rackspace.comwrote: 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
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant rbry...@redhat.com wrote: On 11/29/2013 01:39 PM, Doug Hellmann wrote: We have a review up (https://review.openstack.org/#/c/58297/) to add some features to the notification system in the oslo incubator. THe notification system is being moved into oslo.messaging, and so we have the question of whether to accept the patch to the incubated version, move it to oslo.messaging, or carry it in both. As I say in the review, from a practical standpoint I think we can't really support continued development in both places. Given the number of times the topic of just make everything a library has come up, I would prefer that we focus our energy on completing the transition for a given module or library once it the process starts. We also need to avoid feature drift, and provide a clear incentive for projects to update to the new library. 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. Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. +1 in general. You may want to make after it starts moving into a library more specific, though. I think my word choice is probably what threw Sandy off, too. How about after it has been moved into a library with at least a release candidate published? One approach could be to reflect this status in the MAINTAINERS file. Right now there is a status field for each module in the incubator: S: Status, one of the following: Maintained: Has an active maintainer Orphan: No current maintainer, feel free to step up! Obsolete:Replaced by newer code, or a dead end, or out-dated It seems that the types of code we're talking about should just be marked as Obsolete. Obsolete code should only get stable-like bug fixes. That would mean marking 'rpc' and 'notifier' as Obsolete (currently listed as Maintained). I think that is accurate, though. Good point. Doug https://review.openstack.org/59367 -- Russell Bryant ___ 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
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant rbry...@redhat.com wrote: On 11/29/2013 01:39 PM, Doug Hellmann wrote: We have a review up (https://review.openstack.org/#/c/58297/) to add some features to the notification system in the oslo incubator. THe notification system is being moved into oslo.messaging, and so we have the question of whether to accept the patch to the incubated version, move it to oslo.messaging, or carry it in both. As I say in the review, from a practical standpoint I think we can't really support continued development in both places. Given the number of times the topic of just make everything a library has come up, I would prefer that we focus our energy on completing the transition for a given module or library once it the process starts. We also need to avoid feature drift, and provide a clear incentive for projects to update to the new library. 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. Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. +1 in general. You may want to make after it starts moving into a library more specific, though. I think my word choice is probably what threw Sandy off, too. How about after it has been moved into a library with at least a release candidate published? One approach could be to reflect this status in the MAINTAINERS file. Right now there is a status field for each module in the incubator: S: Status, one of the following: Maintained: Has an active maintainer Orphan: No current maintainer, feel free to step up! Obsolete:Replaced by newer code, or a dead end, or out-dated It seems that the types of code we're talking about should just be marked as Obsolete. Obsolete code should only get stable-like bug fixes. That would mean marking 'rpc' and 'notifier' as Obsolete (currently listed as Maintained). I think that is accurate, though. Good point. I also added a Graduating status as an indicator for code in that intermediate phase where there are 2 copies to be maintained. I hope we don't have to use it very often, but it's best to be explicit. https://review.openstack.org/#/c/59373/ Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On 12/02/2013 08:53 AM, Doug Hellmann wrote: On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com wrote: On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 11/29/2013 01:39 PM, Doug Hellmann wrote: We have a review up (https://review.openstack.org/#/c/58297/) to add some features to the notification system in the oslo incubator. THe notification system is being moved into oslo.messaging, and so we have the question of whether to accept the patch to the incubated version, move it to oslo.messaging, or carry it in both. As I say in the review, from a practical standpoint I think we can't really support continued development in both places. Given the number of times the topic of just make everything a library has come up, I would prefer that we focus our energy on completing the transition for a given module or library once it the process starts. We also need to avoid feature drift, and provide a clear incentive for projects to update to the new library. 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. Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. +1 in general. You may want to make after it starts moving into a library more specific, though. I think my word choice is probably what threw Sandy off, too. How about after it has been moved into a library with at least a release candidate published? Sure, that's better. That gives a specific bit of criteria for when the switch is flipped. One approach could be to reflect this status in the MAINTAINERS file. Right now there is a status field for each module in the incubator: S: Status, one of the following: Maintained: Has an active maintainer Orphan: No current maintainer, feel free to step up! Obsolete:Replaced by newer code, or a dead end, or out-dated It seems that the types of code we're talking about should just be marked as Obsolete. Obsolete code should only get stable-like bug fixes. That would mean marking 'rpc' and 'notifier' as Obsolete (currently listed as Maintained). I think that is accurate, though. Good point. So, to clarify, possible flows would be: 1) An API moving to a library as-is, like rootwrap Status: Maintained - Status: Graduating (short term) - Code removed from oslo-incubator once library is released 2) An API being replaced with a better one, like rpc being replaced by oslo.messaging Status: Maintained - Status: Obsolete (once an RC of a replacement lib has been released) - Code removed from oslo-incubator once all integrated projects have been migrated off of the obsolete code Does that match your view? I also added a Graduating status as an indicator for code in that intermediate phase where there are 2 copies to be maintained. I hope we don't have to use it very often, but it's best to be explicit. https://review.openstack.org/#/c/59373/ Sounds good to me. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Mon, Dec 2, 2013 at 9:06 AM, Russell Bryant rbry...@redhat.com wrote: On 12/02/2013 08:53 AM, Doug Hellmann wrote: On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com wrote: On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 11/29/2013 01:39 PM, Doug Hellmann wrote: We have a review up (https://review.openstack.org/#/c/58297/) to add some features to the notification system in the oslo incubator. THe notification system is being moved into oslo.messaging, and so we have the question of whether to accept the patch to the incubated version, move it to oslo.messaging, or carry it in both. As I say in the review, from a practical standpoint I think we can't really support continued development in both places. Given the number of times the topic of just make everything a library has come up, I would prefer that we focus our energy on completing the transition for a given module or library once it the process starts. We also need to avoid feature drift, and provide a clear incentive for projects to update to the new library. 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. Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. +1 in general. You may want to make after it starts moving into a library more specific, though. I think my word choice is probably what threw Sandy off, too. How about after it has been moved into a library with at least a release candidate published? Sure, that's better. That gives a specific bit of criteria for when the switch is flipped. One approach could be to reflect this status in the MAINTAINERS file. Right now there is a status field for each module in the incubator: S: Status, one of the following: Maintained: Has an active maintainer Orphan: No current maintainer, feel free to step up! Obsolete:Replaced by newer code, or a dead end, or out-dated It seems that the types of code we're talking about should just be marked as Obsolete. Obsolete code should only get stable-like bug fixes. That would mean marking 'rpc' and 'notifier' as Obsolete (currently listed as Maintained). I think that is accurate, though. Good point. So, to clarify, possible flows would be: 1) An API moving to a library as-is, like rootwrap Status: Maintained - Status: Graduating (short term) - Code removed from oslo-incubator once library is released I think it's ok to mark it as obsolete for a short time, after the release, until we are sure that the adoption will be as painless as we expect. I'm not sure we need a hard rule here, but I do agree that the distinction is the degree to which the API has changed. 2) An API being replaced with a better one, like rpc being replaced by oslo.messaging Status: Maintained - Status: Obsolete (once an RC of a replacement lib has been released) - Code removed from oslo-incubator once all integrated projects have been migrated off of the obsolete code Does that match your view? If we had been using the graduating status, the rpc, zmq, and notifications modules would have been marked as graduating during the havana cycle, too. I also added a Graduating status as an indicator for code in that intermediate phase where there are 2 copies to be maintained. I hope we don't have to use it very often, but it's best to be explicit. https://review.openstack.org/#/c/59373/ Sounds good to me. -- Russell Bryant ___ 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
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant rbry...@redhat.com wrote: On 12/02/2013 08:53 AM, Doug Hellmann wrote: On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com wrote: On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 11/29/2013 01:39 PM, Doug Hellmann wrote: We have a review up (https://review.openstack.org/#/c/58297/) to add some features to the notification system in the oslo incubator. THe notification system is being moved into oslo.messaging, and so we have the question of whether to accept the patch to the incubated version, move it to oslo.messaging, or carry it in both. As I say in the review, from a practical standpoint I think we can't really support continued development in both places. Given the number of times the topic of just make everything a library has come up, I would prefer that we focus our energy on completing the transition for a given module or library once it the process starts. We also need to avoid feature drift, and provide a clear incentive for projects to update to the new library. 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. Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. +1 in general. You may want to make after it starts moving into a library more specific, though. I think my word choice is probably what threw Sandy off, too. How about after it has been moved into a library with at least a release candidate published? Sure, that's better. That gives a specific bit of criteria for when the switch is flipped. One approach could be to reflect this status in the MAINTAINERS file. Right now there is a status field for each module in the incubator: S: Status, one of the following: Maintained: Has an active maintainer Orphan: No current maintainer, feel free to step up! Obsolete:Replaced by newer code, or a dead end, or out-dated It seems that the types of code we're talking about should just be marked as Obsolete. Obsolete code should only get stable-like bug fixes. That would mean marking 'rpc' and 'notifier' as Obsolete (currently listed as Maintained). I think that is accurate, though. Good point. So, to clarify, possible flows would be: 1) An API moving to a library as-is, like rootwrap Status: Maintained - Status: Graduating (short term) - Code removed from oslo-incubator once library is released 2) An API being replaced with a better one, like rpc being replaced by oslo.messaging Status: Maintained - Status: Obsolete (once an RC of a replacement lib has been released) - Code removed from oslo-incubator once all integrated projects have been migrated off of the obsolete code Does that match your view? I also added a Graduating status as an indicator for code in that intermediate phase where there are 2 copies to be maintained. I hope we don't have to use it very often, but it's best to be explicit. https://review.openstack.org/#/c/59373/ Sounds good to me. So is messaging in 'graduating' since it isn't used by all core projects yet (nova - https://review.openstack.org/#/c/39929/)? -- Russell Bryant ___ 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
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On 02/12/13 09:06 -0500, Russell Bryant wrote: On 12/02/2013 08:53 AM, Doug Hellmann wrote: So, to clarify, possible flows would be: 1) An API moving to a library as-is, like rootwrap Status: Maintained - Status: Graduating (short term) - Code removed from oslo-incubator once library is released We should make the module print a deprecation warning which would be more like a 'transition' warning. So that people know the module is being moved to it's own package. 2) An API being replaced with a better one, like rpc being replaced by oslo.messaging Status: Maintained - Status: Obsolete (once an RC of a replacement lib has been released) - Code removed from oslo-incubator once all integrated projects have been migrated off of the obsolete code We've a deprecated package in oslo-incubator. It may complicate things a bit but, moving obsolete packages there may make sense. I'd also update the module - or package - and make it print a deprecation warning. FF -- @flaper87 Flavio Percoco pgpNqMKh1PkJM.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant rbry...@redhat.com wrote: On 12/02/2013 08:53 AM, Doug Hellmann wrote: On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com wrote: On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 11/29/2013 01:39 PM, Doug Hellmann wrote: We have a review up (https://review.openstack.org/#/c/58297/) to add some features to the notification system in the oslo incubator. THe notification system is being moved into oslo.messaging, and so we have the question of whether to accept the patch to the incubated version, move it to oslo.messaging, or carry it in both. As I say in the review, from a practical standpoint I think we can't really support continued development in both places. Given the number of times the topic of just make everything a library has come up, I would prefer that we focus our energy on completing the transition for a given module or library once it the process starts. We also need to avoid feature drift, and provide a clear incentive for projects to update to the new library. 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. Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. +1 in general. You may want to make after it starts moving into a library more specific, though. I think my word choice is probably what threw Sandy off, too. How about after it has been moved into a library with at least a release candidate published? Sure, that's better. That gives a specific bit of criteria for when the switch is flipped. One approach could be to reflect this status in the MAINTAINERS file. Right now there is a status field for each module in the incubator: S: Status, one of the following: Maintained: Has an active maintainer Orphan: No current maintainer, feel free to step up! Obsolete:Replaced by newer code, or a dead end, or out-dated It seems that the types of code we're talking about should just be marked as Obsolete. Obsolete code should only get stable-like bug fixes. That would mean marking 'rpc' and 'notifier' as Obsolete (currently listed as Maintained). I think that is accurate, though. Good point. So, to clarify, possible flows would be: 1) An API moving to a library as-is, like rootwrap Status: Maintained - Status: Graduating (short term) - Code removed from oslo-incubator once library is released 2) An API being replaced with a better one, like rpc being replaced by oslo.messaging Status: Maintained - Status: Obsolete (once an RC of a replacement lib has been released) - Code removed from oslo-incubator once all integrated projects have been migrated off of the obsolete code Does that match your view? I also added a Graduating status as an indicator for code in that intermediate phase where there are 2 copies to be maintained. I hope we don't have to use it very often, but it's best to be explicit. https://review.openstack.org/#/c/59373/ Sounds good to me. So is messaging in 'graduating' since it isn't used by all core projects yet (nova - https://review.openstack.org/#/c/39929/)? Graduation is a status within the oslo project, not the other projects. We can't control adoption downstream, so I am trying to set a reasonable policy for maintenance until we have an official release. Graduating means there is a git repo with a library but the library has no releases yet. Obsolete means there is a library, but we are providing a grace period for adoption during which critical issues in the incubated version of the code will be accepted -- but no features. Doug -- Russell Bryant ___ OpenStack-dev mailing list
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Mon, Dec 2, 2013 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote: On 02/12/13 09:06 -0500, Russell Bryant wrote: On 12/02/2013 08:53 AM, Doug Hellmann wrote: So, to clarify, possible flows would be: 1) An API moving to a library as-is, like rootwrap Status: Maintained - Status: Graduating (short term) - Code removed from oslo-incubator once library is released We should make the module print a deprecation warning which would be more like a 'transition' warning. So that people know the module is being moved to it's own package. I thought about that, too. We could do it, but it feels like code churn. I would rather spend the effort on updating projects to have the libraries adopted. 2) An API being replaced with a better one, like rpc being replaced by oslo.messaging Status: Maintained - Status: Obsolete (once an RC of a replacement lib has been released) - Code removed from oslo-incubator once all integrated projects have been migrated off of the obsolete code We've a deprecated package in oslo-incubator. It may complicate things a bit but, moving obsolete packages there may make sense. I'd also update the module - or package - and make it print a deprecation warning. The deprecated package is for modules we are no longer maintaining but for which there is not a direct replacement. Right now that only applies to the wsgi module, since Pecan isn't an Oslo library. Doug FF -- @flaper87 Flavio Percoco ___ 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
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Mon, Dec 2, 2013 at 10:26 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Mon, Dec 2, 2013 at 10:05 AM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Dec 2, 2013 at 6:37 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon joe.gord...@gmail.comwrote: On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant rbry...@redhat.comwrote: On 12/02/2013 08:53 AM, Doug Hellmann wrote: On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com wrote: On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 11/29/2013 01:39 PM, Doug Hellmann wrote: We have a review up ( https://review.openstack.org/#/c/58297/) to add some features to the notification system in the oslo incubator. THe notification system is being moved into oslo.messaging, and so we have the question of whether to accept the patch to the incubated version, move it to oslo.messaging, or carry it in both. As I say in the review, from a practical standpoint I think we can't really support continued development in both places. Given the number of times the topic of just make everything a library has come up, I would prefer that we focus our energy on completing the transition for a given module or library once it the process starts. We also need to avoid feature drift, and provide a clear incentive for projects to update to the new library. 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. Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. +1 in general. You may want to make after it starts moving into a library more specific, though. I think my word choice is probably what threw Sandy off, too. How about after it has been moved into a library with at least a release candidate published? Sure, that's better. That gives a specific bit of criteria for when the switch is flipped. One approach could be to reflect this status in the MAINTAINERS file. Right now there is a status field for each module in the incubator: S: Status, one of the following: Maintained: Has an active maintainer Orphan: No current maintainer, feel free to step up! Obsolete:Replaced by newer code, or a dead end, or out-dated It seems that the types of code we're talking about should just be marked as Obsolete. Obsolete code should only get stable-like bug fixes. That would mean marking 'rpc' and 'notifier' as Obsolete (currently listed as Maintained). I think that is accurate, though. Good point. So, to clarify, possible flows would be: 1) An API moving to a library as-is, like rootwrap Status: Maintained - Status: Graduating (short term) - Code removed from oslo-incubator once library is released 2) An API being replaced with a better one, like rpc being replaced by oslo.messaging Status: Maintained - Status: Obsolete (once an RC of a replacement lib has been released) - Code removed from oslo-incubator once all integrated projects have been migrated off of the obsolete code Does that match your view? I also added a Graduating status as an indicator for code in that intermediate phase where there are 2 copies to be maintained. I hope we don't have to use it very often, but it's best to be explicit. https://review.openstack.org/#/c/59373/ Sounds good to me. So is messaging in 'graduating' since it isn't used by all core projects yet (nova - https://review.openstack.org/#/c/39929/)? Graduation is a status within the oslo project, not the other projects. We can't control adoption downstream, so I am trying to set a reasonable policy for maintenance until we have an official release. Although oslo cannot fully control downstream adaption, they can help facilitate that process, we are all in the same
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Mon, Dec 2, 2013 at 7:26 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Mon, Dec 2, 2013 at 10:05 AM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Dec 2, 2013 at 6:37 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon joe.gord...@gmail.comwrote: On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant rbry...@redhat.comwrote: On 12/02/2013 08:53 AM, Doug Hellmann wrote: On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com wrote: On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 11/29/2013 01:39 PM, Doug Hellmann wrote: We have a review up ( https://review.openstack.org/#/c/58297/) to add some features to the notification system in the oslo incubator. THe notification system is being moved into oslo.messaging, and so we have the question of whether to accept the patch to the incubated version, move it to oslo.messaging, or carry it in both. As I say in the review, from a practical standpoint I think we can't really support continued development in both places. Given the number of times the topic of just make everything a library has come up, I would prefer that we focus our energy on completing the transition for a given module or library once it the process starts. We also need to avoid feature drift, and provide a clear incentive for projects to update to the new library. 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. Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. +1 in general. You may want to make after it starts moving into a library more specific, though. I think my word choice is probably what threw Sandy off, too. How about after it has been moved into a library with at least a release candidate published? Sure, that's better. That gives a specific bit of criteria for when the switch is flipped. One approach could be to reflect this status in the MAINTAINERS file. Right now there is a status field for each module in the incubator: S: Status, one of the following: Maintained: Has an active maintainer Orphan: No current maintainer, feel free to step up! Obsolete:Replaced by newer code, or a dead end, or out-dated It seems that the types of code we're talking about should just be marked as Obsolete. Obsolete code should only get stable-like bug fixes. That would mean marking 'rpc' and 'notifier' as Obsolete (currently listed as Maintained). I think that is accurate, though. Good point. So, to clarify, possible flows would be: 1) An API moving to a library as-is, like rootwrap Status: Maintained - Status: Graduating (short term) - Code removed from oslo-incubator once library is released 2) An API being replaced with a better one, like rpc being replaced by oslo.messaging Status: Maintained - Status: Obsolete (once an RC of a replacement lib has been released) - Code removed from oslo-incubator once all integrated projects have been migrated off of the obsolete code Does that match your view? I also added a Graduating status as an indicator for code in that intermediate phase where there are 2 copies to be maintained. I hope we don't have to use it very often, but it's best to be explicit. https://review.openstack.org/#/c/59373/ Sounds good to me. So is messaging in 'graduating' since it isn't used by all core projects yet (nova - https://review.openstack.org/#/c/39929/)? Graduation is a status within the oslo project, not the other projects. We can't control adoption downstream, so I am trying to set a reasonable policy for maintenance until we have an official release. Although oslo cannot fully control downstream adaption, they can help facilitate that process, we are all in the same
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Sat, Nov 30, 2013 at 3:52 PM, Sandy Walsh sandy.wa...@rackspace.comwrote: 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 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? Doug Doug -S From: Eric Windisch [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 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
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
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 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. Doug -S From: Eric Windisch [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 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] [oslo] maintenance policy for code graduating from the incubator
We have a review up (https://review.openstack.org/#/c/58297/) to add some features to the notification system in the oslo incubator. THe notification system is being moved into oslo.messaging, and so we have the question of whether to accept the patch to the incubated version, move it to oslo.messaging, or carry it in both. As I say in the review, from a practical standpoint I think we can't really support continued development in both places. Given the number of times the topic of just make everything a library has come up, I would prefer that we focus our energy on completing the transition for a given module or library once it the process starts. We also need to avoid feature drift, and provide a clear incentive for projects to update to the new library. 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. Before we make this policy official, I want to solicit feedback from the rest of the community and the Oslo core team. Thanks, Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
Doug, 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. Sounds good and right. Best regards, Boris Pavlovic On Fri, Nov 29, 2013 at 10:47 PM, Eric Windisch e...@cloudscaling.comwrote: 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 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
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
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. -S From: Eric Windisch [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 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
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On Fri, Nov 29, 2013 at 2:14 PM, Sandy Walsh sandy.wa...@rackspace.comwrote: 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? Doug -S From: Eric Windisch [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 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
