[openstack-dev] [oslo] maintenance policy for code graduating from the incubator

Doug Hellmann doug.hellmann at dreamhost.com
Mon Dec 2 13:53:49 UTC 2013

On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann
<doug.hellmann at dreamhost.com>wrote:

> On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant <rbryant at 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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131202/133cc8ba/attachment.html>

More information about the OpenStack-dev mailing list