Open Stack

On 12/02/2013 08:53 AM, Doug Hellmann wrote:
> 
> 
> 
> On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann
> <doug.hellmann at dreamhost.com <mailto:doug.hellmann at dreamhost.com>> wrote:
> 
> 
> 
> 
>     On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant <rbryant at redhat.com
>     <mailto: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"?

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.

-- 
Russell Bryant