On Mon, Dec 2, 2013 at 10:05 AM, Joe Gordon <[email protected]> wrote:
> > > > On Mon, Dec 2, 2013 at 6:37 AM, Doug Hellmann <[email protected] > > wrote: > >> >> >> >> On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon <[email protected]> wrote: >> >>> >>> >>> >>> On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant <[email protected]>wrote: >>> >>>> On 12/02/2013 08:53 AM, Doug Hellmann wrote: >>>> > >>>> > >>>> > >>>> > On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann >>>> > <[email protected] <mailto:[email protected]>> >>>> wrote: >>>> > >>>> > >>>> > >>>> > >>>> > On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant < >>>> [email protected] >>>> > <mailto:[email protected]>> 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. Doug
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
