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. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
