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