<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 10:05 AM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div><div class="h5">On Mon, Dec 2, 2013 at 6:37 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div><div class="gmail_extra">
<br><br><div class="gmail_quote"><div><div>
On Mon, Dec 2, 2013 at 9:22 AM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div><div>On Mon, Dec 2, 2013 at 6: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>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>> <<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a> <mailto:<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">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" target="_blank">rbryant@redhat.com</a><br>
</div><div><div>> <mailto:<a href="mailto:rbryant@redhat.com" target="_blank">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><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>
<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>
<div><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><div><br></div></div></blockquote><div><br></div></div></div><div>So is messaging in 'graduating' since it isn't used by all core projects yet (nova - <a href="https://review.openstack.org/#/c/39929/" target="_blank">https://review.openstack.org/#/c/39929/</a>)?</div>
</div></div></div></blockquote><div><br></div></div></div><div><div style="font-size:small">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.</div>
</div></div></div></div></blockquote><div><br></div></div></div><div>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.</div>
</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>
<div style="font-size:small"><br></div><div style="font-size:small">Graduating means there is a git repo with a library but the library has no releases yet.</div><div style="font-size:small">
<br></div><div style="font-size:small">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.</div>
</div></div></div></div></blockquote><div><br></div></div><div>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?</div>
</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div></div></div><br></div></div>