On Mon, Dec 2, 2013 at 7:26 AM, Doug Hellmann <doug.hellm...@dreamhost.com>wrote:
> > > > 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.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. >>> >> >> Although oslo cannot fully control downstream adaption, they can help >> facilitate that process, we are all in the same project after all. I don't >> think having some adoption metrics for core projects tied into an oslo >> status should be too much of an additional burden. From the downstream >> point of view, I see the migration to a library as the last step of an >> oslo-incubator sync. And as we have have recently seen, that process is >> rarely initiated by the downstream project. >> > > Sure, but that's what the "obsolete" status already represents. The new > status is just for the period of time when we are working on moving the > code into a library in a separate repo, as an indicator for contributors > who may not be aware of that work. > > > >> >> >>> 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. >>> >> >> Thanks for the clarification. To make sure I am getting this right: RPC >> in oslo-incubator is considered obsolete, since we have oslo.messaging, and >> the only way Sandy can get his patch used by nova is to help move nova to >> oslo.messaging? >> > > In the general case, it is correct to say that new features would need to > make it to oslo.messaging at this point. In this specific case the notifier > is a plugin and so it could be released in any number of ways. The > notification subscription classes are a better example of a feature that is > being added to oslo.messaging that would be more difficult to use until it > lands there. > Thanks, that answers all my questions. > Doug > > > _______________________________________________ > 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