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. > 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? > > Doug > > > >> >> -- >>> 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 >> >> > > _______________________________________________ > 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
