Open Stack

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

>
>
>
> On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>>
>>
>>
>> On Mon, Dec 2, 2013 at 6: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
>>>
>>> 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.
>

Although oslo cannot fully control downstream adaption, they can help
facilitate that process, we are all in the same project after all. I don't
think having some adoption metrics for core projects tied into an oslo
status should be too much of an additional burden.  From the downstream
point of view, I see the migration to a library as the last step of an
oslo-incubator sync. And as we have have recently seen, that process is
rarely initiated by the downstream project.


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

Thanks for the clarification. To make sure I am getting this right: RPC in
oslo-incubator is considered obsolete, since we have oslo.messaging, and
the only way Sandy can get his patch used by nova is to help move nova to
oslo.messaging?


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