<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 2, 2013 at 9:06 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/02/2013 08:53 AM, Doug Hellmann wrote:<br>
><br>
><br>
><br>
> On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann<br>
</div><div class="im">> <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a> <mailto:<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>>> wrote:<br>
><br>
><br>
><br>
><br>
> On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>>> wrote:<br>
><br>
> On 11/29/2013 01:39 PM, Doug Hellmann wrote:<br>
> > We have a review up (<a href="https://review.openstack.org/#/c/58297/" target="_blank">https://review.openstack.org/#/c/58297/</a>)<br>
> to add<br>
> > some features to the notification system in the oslo<br>
> incubator. THe<br>
> > notification system is being moved into oslo.messaging, and so<br>
> we have<br>
> > the question of whether to accept the patch to the incubated<br>
> version,<br>
> > move it to oslo.messaging, or carry it in both.<br>
> ><br>
> > As I say in the review, from a practical standpoint I think we<br>
> can't<br>
> > really support continued development in both places. Given the<br>
> number of<br>
> > times the topic of "just make everything a library" has come<br>
> up, I would<br>
> > prefer that we focus our energy on completing the transition<br>
> for a given<br>
> > module or library once it the process starts. We also need to<br>
> avoid<br>
> > feature drift, and provide a clear incentive for projects to<br>
> update to<br>
> > the new library.<br>
> ><br>
> > Based on that, I would like to say that we do not add new<br>
> features to<br>
> > incubated code after it starts moving into a library, and only<br>
> provide<br>
> > "stable-like" bug fix support until integrated projects are<br>
> moved over<br>
> > to the graduated library (although even that is up for<br>
> discussion).<br>
> > After all integrated projects that use the code are using the<br>
> library<br>
> > instead of the incubator, we can delete the module(s) from the<br>
> incubator.<br>
> ><br>
> > Before we make this policy official, I want to solicit<br>
> feedback from the<br>
> > rest of the community and the Oslo core team.<br>
><br>
> +1 in general.<br>
><br>
> You may want to make "after it starts moving into a library" more<br>
> specific, though.<br>
><br>
><br>
> I think my word choice is probably what threw Sandy off, too.<br>
><br>
> How about "after it has been moved into a library with at least a<br>
> release candidate published"?<br>
<br>
</div></div>Sure, that's better. That gives a specific bit of criteria for when the<br>
switch is flipped.<br>
<div class="im"><br>
><br>
><br>
> One approach could be to reflect this status in the<br>
> MAINTAINERS file. Right now there is a status field for each<br>
> module in<br>
> the incubator:<br>
><br>
><br>
> S: Status, one of the following:<br>
> Maintained: Has an active maintainer<br>
> Orphan: No current maintainer, feel free to step up!<br>
> Obsolete: Replaced by newer code, or a dead end, or<br>
> out-dated<br>
><br>
> It seems that the types of code we're talking about should just be<br>
> marked as Obsolete. Obsolete code should only get stable-like<br>
> bug fixes.<br>
><br>
> That would mean marking 'rpc' and 'notifier' as Obsolete (currently<br>
> listed as Maintained). I think that is accurate, though.<br>
><br>
><br>
> Good point.<br>
<br>
</div>So, to clarify, possible flows would be:<br>
<br>
1) An API moving to a library as-is, like rootwrap<br>
<br>
Status: Maintained<br>
-> Status: Graduating (short term)<br>
-> Code removed from oslo-incubator once library is released<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) An API being replaced with a better one, like rpc being replaced by<br>
oslo.messaging<br>
<br>
Status: Maintained<br>
-> Status: Obsolete (once an RC of a replacement lib has been released)<br>
-> Code removed from oslo-incubator once all integrated projects have<br>
been migrated off of the obsolete code<br>
<br>
<br>
Does that match your view?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> I also added a "Graduating" status as an indicator for code in that<br>
> intermediate phase where there are 2 copies to be maintained. I hope we<br>
> don't have to use it very often, but it's best to be explicit.<br>
><br>
> <a href="https://review.openstack.org/#/c/59373/" target="_blank">https://review.openstack.org/#/c/59373/</a><br>
<br>
</div>Sounds good to me.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>