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

[Mark McLoughlin]

On Mon, 2013-12-02 at 11:00 -0500, Doug Hellmann wrote:

> I have updated the Oslo wiki page with these details and would appreciate
> feedback on the wording used there.
> 
> https://wiki.openstack.org/wiki/Oslo#Graduation

Thanks Doug, that sounds perfect to me.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Joe Gordon]

On Mon, Dec 2, 2013 at 7:26 AM, Doug Hellmann
wrote:

>
>
>
> On Mon, Dec 2, 2013 at 10:05 AM, Joe Gordon  wrote:
>
>>
>>
>>
>> On Mon, Dec 2, 2013 at 6:37 AM, Doug Hellmann <
>> doug.hellm...@dreamhost.com> wrote:
>>
>>>
>>>
>>>
>>> On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon wrote:
>>>



 On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant wrote:

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

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

[Doug Hellmann]

On Mon, Dec 2, 2013 at 10:26 AM, Doug Hellmann
wrote:

>
>
>
> On Mon, Dec 2, 2013 at 10:05 AM, Joe Gordon  wrote:
>
>>
>>
>>
>> On Mon, Dec 2, 2013 at 6:37 AM, Doug Hellmann <
>> doug.hellm...@dreamhost.com> wrote:
>>
>>>
>>>
>>>
>>> On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon wrote:
>>>



 On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant wrote:

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

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

[Doug Hellmann]

On Mon, Dec 2, 2013 at 10:05 AM, Joe Gordon  wrote:

>
>
>
> On Mon, Dec 2, 2013 at 6:37 AM, Doug Hellmann  > wrote:
>
>>
>>
>>
>> On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon  wrote:
>>
>>>
>>>
>>>
>>> On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant wrote:
>>>
 On 12/02/2013 08:53 AM, Doug Hellmann wrote:
 >
 >
 >
 > On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann
 > mailto:doug.hellm...@dreamhost.com>>
 wrote:
 >
 >
 >
 >
 > On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant <
 rbry...@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/#

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

[Joe Gordon]

On Mon, Dec 2, 2013 at 6:37 AM, Doug Hellmann
wrote:

>
>
>
> On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon  wrote:
>
>>
>>
>>
>> On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant wrote:
>>
>>> On 12/02/2013 08:53 AM, Doug Hellmann wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann
>>> > mailto:doug.hellm...@dreamhost.com>>
>>> wrote:
>>> >
>>> >
>>> >
>>> >
>>> > On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant >> > > 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 proj

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

[Flavio Percoco]

On 02/12/13 09:40 -0500, Doug Hellmann wrote:




On Mon, Dec 2, 2013 at 9:25 AM, Flavio Percoco  wrote:

   On 02/12/13 09:06 -0500, Russell Bryant wrote:

   On 12/02/2013 08:53 AM, Doug Hellmann wrote:
   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


   We should make the module print a deprecation warning which would be
   more like a 'transition' warning. So that people know the module is
   being moved to it's own package.


I thought about that, too. We could do it, but it feels like code churn. I
would rather spend the effort on updating projects to have the libraries
adopted.


I was thinking more about updating the oslo module / package without
updating them in every OS project. If people syncs the oslo-incubator
code, they'll pull the warning in as well.



   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


   We've a deprecated package in oslo-incubator. It may complicate things
   a bit but, moving obsolete packages there may make sense. I'd also
   update the module - or package - and make it print a deprecation
   warning.


The deprecated package is for modules we are no longer maintaining but for
which there is not a direct replacement. Right now that only applies to the
wsgi module, since Pecan isn't an Oslo library.



Makes sense!

FF

--
@flaper87
Flavio Percoco


pgp3v0KVtLPd0.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

On Mon, Dec 2, 2013 at 9:25 AM, Flavio Percoco  wrote:

> On 02/12/13 09:06 -0500, Russell Bryant wrote:
>
>> On 12/02/2013 08:53 AM, Doug Hellmann wrote:
>> 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
>>
>
> We should make the module print a deprecation warning which would be
> more like a 'transition' warning. So that people know the module is
> being moved to it's own package.


I thought about that, too. We could do it, but it feels like code churn. I
would rather spend the effort on updating projects to have the libraries
adopted.



>
>
>
>> 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
>>
>
> We've a deprecated package in oslo-incubator. It may complicate things
> a bit but, moving obsolete packages there may make sense. I'd also
> update the module - or package - and make it print a deprecation
> warning.


The deprecated package is for modules we are no longer maintaining but for
which there is not a direct replacement. Right now that only applies to the
wsgi module, since Pecan isn't an Oslo library.

Doug



>
>
> FF
>
> --
> @flaper87
> Flavio Percoco
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon  wrote:

>
>
>
> On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant  wrote:
>
>> On 12/02/2013 08:53 AM, Doug Hellmann wrote:
>> >
>> >
>> >
>> > On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann
>> > mailto:doug.hellm...@dreamhost.com>>
>> wrote:
>> >
>> >
>> >
>> >
>> > On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant > > > 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.

Graduating means there is a git repo with a library but the library has no
releases yet.

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

[Flavio Percoco]

On 02/12/13 09:06 -0500, Russell Bryant wrote:

On 12/02/2013 08:53 AM, Doug Hellmann wrote:
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


We should make the module print a deprecation warning which would be
more like a 'transition' warning. So that people know the module is
being moved to it's own package.



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


We've a deprecated package in oslo-incubator. It may complicate things
a bit but, moving obsolete packages there may make sense. I'd also
update the module - or package - and make it print a deprecation
warning.

FF

--
@flaper87
Flavio Percoco


pgpNqMKh1PkJM.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Joe Gordon]

On Mon, Dec 2, 2013 at 6:06 AM, Russell Bryant  wrote:

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

--
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

On Mon, Dec 2, 2013 at 9:06 AM, Russell Bryant  wrote:

> On 12/02/2013 08:53 AM, Doug Hellmann wrote:
> >
> >
> >
> > On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann
> > mailto:doug.hellm...@dreamhost.com>>
> wrote:
> >
> >
> >
> >
> > On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant  > > 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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listi

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

[Russell Bryant]

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann
wrote:

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

https://review.openstack.org/#/c/59373/

Doug

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

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

Doug



>
> https://review.openstack.org/59367
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

On Mon, Dec 2, 2013 at 8:08 AM, Sandy Walsh wrote:

>
>
> On 12/01/2013 06:40 PM, Doug Hellmann wrote:
> >
> >
> >
> > On Sat, Nov 30, 2013 at 3:52 PM, Sandy Walsh  > <mailto:sandy.wa...@rackspace.com>> wrote:
> >
> >
> >
> > On 11/29/2013 03:58 PM, Doug Hellmann wrote:
> > >
> > >
> > >
> > > On Fri, Nov 29, 2013 at 2:14 PM, Sandy Walsh
> > mailto:sandy.wa...@rackspace.com>
> > > <mailto:sandy.wa...@rackspace.com
> > <mailto:sandy.wa...@rackspace.com>>> wrote:
> > >
> > > So, as I mention in the branch, what about deployments that
> > haven't
> > > transitioned to the library but would like to cherry pick this
> > feature?
> > >
> > > "after it starts moving into a library" can leave a very big
> gap
> > > when the functionality isn't available to users.
> > >
> > >
> > > Are those deployments tracking trunk or a stable branch? Because
> IIUC,
> > > we don't add features like this to stable branches for the main
> > > components, either, and if they are tracking trunk then they will
> get
> > > the new feature when it ships in a project that uses it. Are you
> > > suggesting something in between?
> >
> > Tracking trunk. If the messaging branch has already landed in Nova,
> then
> > this is a moot discussion. Otherwise we'll still need it in
> incubator.
> >
> > That said, consider if messaging wasn't in nova trunk. According to
> this
> > policy the new functionality would have to wait until it was. And, as
> > we've seen with messaging, that was a very long time. That doesn't
> seem
> > reasonable.
> >
> >
> > The alternative is feature drift between the incubated version of rpc
> > and oslo.messaging, which makes the task of moving the other projects to
> > messaging even *harder*.
> >
> > What I'm proposing seems like a standard deprecation/backport policy;
> > I'm not sure why you see the situation as different. Sandy, can you
> > elaborate on how you would expect to maintain feature parity between the
> > incubator and library while projects are in transition?
>
> Deprecation usually assumes there is something in place to replace the
> old way.
>
> If I'm reading this correctly, you're proposing we stop adding to the
> existing library as soon as the new library has started?
>
> Shipping code always wins out. We can't stop development simply based on
> the promise that something new is on the way. Leaving the existing code
> to "bug fix only" status is far too limiting. In the case of messaging
> this would have meant an entire release cycle with no new features in
> oslo.rpc.
>
> Until the new code replaces the old, we have to suffer the pain of
> updating both codebases.
>

I think you misunderstand either my intent or the status of the library.

During Havana we accepted patches to the rpc code and developed
oslo.messaging as a standalone library. Now that oslo.messaging has been
released, it is "shipping code" and the rpc portion of the incubator can be
deprecated during Icehouse.

Doug



>
>
> > Doug
> >
> >
> >
> >
> > >
> > > Doug
> > >
> > >
> > >
> > >
> > > -S
> > >
> > > 
> > > From: Eric Windisch [e...@cloudscaling.com
> > <mailto:e...@cloudscaling.com>
> > > <mailto:e...@cloudscaling.com <mailto:e...@cloudscaling.com>>]
> > > Sent: Friday, November 29, 2013 2:47 PM
> > > To: OpenStack Development Mailing List (not for usage
> questions)
> > > Subject: Re: [openstack-dev] [oslo] maintenance policy for code
> > > graduating from the incubator
> > >
> > > > 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 projec

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

[Russell Bryant]

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

https://review.openstack.org/59367

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sandy Walsh]

On 12/01/2013 06:40 PM, Doug Hellmann wrote:
> 
> 
> 
> On Sat, Nov 30, 2013 at 3:52 PM, Sandy Walsh  <mailto:sandy.wa...@rackspace.com>> wrote:
> 
> 
> 
> On 11/29/2013 03:58 PM, Doug Hellmann wrote:
> >
> >
> >
> > On Fri, Nov 29, 2013 at 2:14 PM, Sandy Walsh
> mailto:sandy.wa...@rackspace.com>
> > <mailto:sandy.wa...@rackspace.com
> <mailto:sandy.wa...@rackspace.com>>> wrote:
> >
> > So, as I mention in the branch, what about deployments that
> haven't
> > transitioned to the library but would like to cherry pick this
> feature?
> >
> > "after it starts moving into a library" can leave a very big gap
> > when the functionality isn't available to users.
> >
> >
> > Are those deployments tracking trunk or a stable branch? Because IIUC,
> > we don't add features like this to stable branches for the main
> > components, either, and if they are tracking trunk then they will get
> > the new feature when it ships in a project that uses it. Are you
> > suggesting something in between?
> 
> Tracking trunk. If the messaging branch has already landed in Nova, then
> this is a moot discussion. Otherwise we'll still need it in incubator.
> 
> That said, consider if messaging wasn't in nova trunk. According to this
> policy the new functionality would have to wait until it was. And, as
> we've seen with messaging, that was a very long time. That doesn't seem
> reasonable.
> 
> 
> The alternative is feature drift between the incubated version of rpc
> and oslo.messaging, which makes the task of moving the other projects to
> messaging even *harder*.
> 
> What I'm proposing seems like a standard deprecation/backport policy;
> I'm not sure why you see the situation as different. Sandy, can you
> elaborate on how you would expect to maintain feature parity between the
> incubator and library while projects are in transition?

Deprecation usually assumes there is something in place to replace the
old way.

If I'm reading this correctly, you're proposing we stop adding to the
existing library as soon as the new library has started?

Shipping code always wins out. We can't stop development simply based on
the promise that something new is on the way. Leaving the existing code
to "bug fix only" status is far too limiting. In the case of messaging
this would have meant an entire release cycle with no new features in
oslo.rpc.

Until the new code replaces the old, we have to suffer the pain of
updating both codebases.


> Doug
> 
>  
> 
> 
> >
> > Doug
> >
> >
> >
> >
> > -S
> >
>     >     ____________________
> > From: Eric Windisch [e...@cloudscaling.com
> <mailto:e...@cloudscaling.com>
> > <mailto:e...@cloudscaling.com <mailto:e...@cloudscaling.com>>]
> > Sent: Friday, November 29, 2013 2:47 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [oslo] maintenance policy for code
> > graduating from the incubator
> >
> > > 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.
> >
> > +1
> >
> > Although never formalized, this is how I had expected we would
> handle
> > the graduation process. It is also how we have been responding to
> > patches and blueprints offerings improvements and feature
> requests for
> > oslo.messaging.
> >
> > --
> > Regards,
> > Eric Windisch
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> <mailto:OpenStack-dev@lists.openstack.org>
> > <mailto:OpenStack-dev@lists.openst

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

[Julien Danjou]

On Fri, Nov 29 2013, Doug Hellmann wrote:

> Before we make this policy official, I want to solicit feedback from the
> rest of the community and the Oslo core team.

+1

I think it's a good idea. It'll push people forward migrating to the
split library if they want the new features.

-- 
Julien Danjou
-- Free Software hacker - independent consultant
-- http://julien.danjou.info


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Flavio Percoco]

On 29/11/13 13:47 -0500, Eric Windisch wrote:

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.


+1

Although never formalized, this is how I had expected we would handle
the graduation process. It is also how we have been responding to
patches and blueprints offerings improvements and feature requests for
oslo.messaging.


+1

FF

--
@flaper87
Flavio Percoco


pgpq0wWsoLCQL.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

On Sat, Nov 30, 2013 at 3:52 PM, Sandy Walsh wrote:

>
>
> On 11/29/2013 03:58 PM, Doug Hellmann wrote:
> >
> >
> >
> > On Fri, Nov 29, 2013 at 2:14 PM, Sandy Walsh  > <mailto:sandy.wa...@rackspace.com>> wrote:
> >
> > So, as I mention in the branch, what about deployments that haven't
> > transitioned to the library but would like to cherry pick this
> feature?
> >
> > "after it starts moving into a library" can leave a very big gap
> > when the functionality isn't available to users.
> >
> >
> > Are those deployments tracking trunk or a stable branch? Because IIUC,
> > we don't add features like this to stable branches for the main
> > components, either, and if they are tracking trunk then they will get
> > the new feature when it ships in a project that uses it. Are you
> > suggesting something in between?
>
> Tracking trunk. If the messaging branch has already landed in Nova, then
> this is a moot discussion. Otherwise we'll still need it in incubator.
>
> That said, consider if messaging wasn't in nova trunk. According to this
> policy the new functionality would have to wait until it was. And, as
> we've seen with messaging, that was a very long time. That doesn't seem
> reasonable.
>

The alternative is feature drift between the incubated version of rpc and
oslo.messaging, which makes the task of moving the other projects to
messaging even *harder*.

What I'm proposing seems like a standard deprecation/backport policy; I'm
not sure why you see the situation as different. Sandy, can you elaborate
on how you would expect to maintain feature parity between the incubator
and library while projects are in transition?

Doug



>
> >
> > Doug
> >
> >
> >
> >
> > -S
> >
> > ____________
> >     From: Eric Windisch [e...@cloudscaling.com
> > <mailto:e...@cloudscaling.com>]
> > Sent: Friday, November 29, 2013 2:47 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [oslo] maintenance policy for code
> > graduating from the incubator
> >
> > > 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.
> >
> > +1
> >
> > Although never formalized, this is how I had expected we would handle
> > the graduation process. It is also how we have been responding to
> > patches and blueprints offerings improvements and feature requests
> for
> > oslo.messaging.
> >
> > --
> > Regards,
> > Eric Windisch
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > <mailto:OpenStack-dev@lists.openstack.org>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > <mailto:OpenStack-dev@lists.openstack.org>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sandy Walsh]

On 11/29/2013 03:58 PM, Doug Hellmann wrote:
> 
> 
> 
> On Fri, Nov 29, 2013 at 2:14 PM, Sandy Walsh  <mailto:sandy.wa...@rackspace.com>> wrote:
> 
> So, as I mention in the branch, what about deployments that haven't
> transitioned to the library but would like to cherry pick this feature?
> 
> "after it starts moving into a library" can leave a very big gap
> when the functionality isn't available to users.
> 
> 
> Are those deployments tracking trunk or a stable branch? Because IIUC,
> we don't add features like this to stable branches for the main
> components, either, and if they are tracking trunk then they will get
> the new feature when it ships in a project that uses it. Are you
> suggesting something in between?

Tracking trunk. If the messaging branch has already landed in Nova, then
this is a moot discussion. Otherwise we'll still need it in incubator.

That said, consider if messaging wasn't in nova trunk. According to this
policy the new functionality would have to wait until it was. And, as
we've seen with messaging, that was a very long time. That doesn't seem
reasonable.

> 
> Doug
> 
>  
> 
> 
> -S
> 
> 
> From: Eric Windisch [e...@cloudscaling.com
> <mailto:e...@cloudscaling.com>]
>     Sent: Friday, November 29, 2013 2:47 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [oslo] maintenance policy for code
> graduating from the incubator
> 
> > 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.
> 
> +1
> 
> Although never formalized, this is how I had expected we would handle
> the graduation process. It is also how we have been responding to
> patches and blueprints offerings improvements and feature requests for
> oslo.messaging.
> 
> --
> Regards,
> Eric Windisch
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

On Fri, Nov 29, 2013 at 2:14 PM, Sandy Walsh wrote:

> So, as I mention in the branch, what about deployments that haven't
> transitioned to the library but would like to cherry pick this feature?
>
> "after it starts moving into a library" can leave a very big gap when the
> functionality isn't available to users.
>

Are those deployments tracking trunk or a stable branch? Because IIUC, we
don't add features like this to stable branches for the main components,
either, and if they are tracking trunk then they will get the new feature
when it ships in a project that uses it. Are you suggesting something in
between?

Doug



>
> -S
>
> 
> From: Eric Windisch [e...@cloudscaling.com]
> Sent: Friday, November 29, 2013 2:47 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [oslo] maintenance policy for code graduating
> from the incubator
>
> > 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.
>
> +1
>
> Although never formalized, this is how I had expected we would handle
> the graduation process. It is also how we have been responding to
> patches and blueprints offerings improvements and feature requests for
> oslo.messaging.
>
> --
> Regards,
> Eric Windisch
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sandy Walsh]

So, as I mention in the branch, what about deployments that haven't 
transitioned to the library but would like to cherry pick this feature? 

"after it starts moving into a library" can leave a very big gap when the 
functionality isn't available to users.

-S


From: Eric Windisch [e...@cloudscaling.com]
Sent: Friday, November 29, 2013 2:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [oslo] maintenance policy for code graduating from 
the incubator

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

+1

Although never formalized, this is how I had expected we would handle
the graduation process. It is also how we have been responding to
patches and blueprints offerings improvements and feature requests for
oslo.messaging.

--
Regards,
Eric Windisch

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Boris Pavlovic]

Doug,


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.


Sounds good and right.


Best regards,
Boris Pavlovic



On Fri, Nov 29, 2013 at 10:47 PM, Eric Windisch wrote:

> > 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.
>
> +1
>
> Although never formalized, this is how I had expected we would handle
> the graduation process. It is also how we have been responding to
> patches and blueprints offerings improvements and feature requests for
> oslo.messaging.
>
> --
> Regards,
> Eric Windisch
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Eric Windisch]

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

+1

Although never formalized, this is how I had expected we would handle
the graduation process. It is also how we have been responding to
patches and blueprints offerings improvements and feature requests for
oslo.messaging.

-- 
Regards,
Eric Windisch

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

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.

Thanks,

Doug
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev