On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann <doug.hellm...@dreamhost.com>wrote:
> > > > On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant <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"? > > > >> 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. > 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/ Doug
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev