Open Stack

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

I think it's ok to mark it as obsolete for a short time, after the release,
until we are sure that the adoption will be as painless as we expect. I'm
not sure we need a hard rule here, but I do agree that the distinction is
the degree to which the API has changed.



>
> 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?
>

If we had been using the "graduating" status, the rpc, zmq, and
notifications modules would have been marked as graduating during the
havana cycle, too.



>
> >
> > 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131202/bd4a257c/attachment.html>