Open Stack

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

>
>
>
> On Mon, Dec 2, 2013 at 10:05 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>>
>>
>>
>> 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.
>>
>
> Sure, but that's what the "obsolete" status already represents. The new
> status is just for the period of time when we are working on moving the
> code into a library in a separate repo, as an indicator for contributors
> who may not be aware of that work.
>
>
>
>>
>>
>>> 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?
>>
>
> In the general case, it is correct to say that new features would need to
> make it to oslo.messaging at this point. In this specific case the notifier
> is a plugin and so it could be released in any number of ways. The
> notification subscription classes are a better example of a feature that is
> being added to oslo.messaging that would be more difficult to use until it
> lands there.
>


Thanks, that answers all my questions.


> Doug
>
>
> _______________________________________________
> 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/91092d2b/attachment.html>