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