<br><br>On Wednesday, December 4, 2013, Flavio Percoco  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/12/13 01:13 +0000, Adrian Otto wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jay is right. What we have is probably close enough to what's in Nova to qualify for oslo-incubator. The simplifications seem to me to have general appeal so this code would be more attractive to other projects. One worry I have is that there is still a good deal of magic behavior in this code, as reviewers have made clear notes about in the code review. I'd like to try it and see if there are further simplifications we could entertain to make this code easier to debug and maintain. It would be great if such iterations happened in a place where other projects could easily leverage them.<br>

<br>
I will remind us that Solum is not currently an incubated project. Should we address this concern now, or during an incubation phase?<br>
</blockquote>
<br>
This is not just a Solum issue but a general issue throughout<br>
OpenStack. The sooner we sort this out, the better.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Some approaches for us to consider:<br>
<br>
1) Merge this code in Solum, open a bug against it to move it back into oslo-incubation, open a stub project in oslo-incubation with a read me that references the bug, and continue iterate on it in Solum until we are reasonably happy with it. Then during an incubation phase, we can resolve that bug by putting the code into oslo-incubation, and achieve the goal of making more reusable work between projects.<br>

<br>
We could also address that bug at such time as any other ecosystem project is looking for a similar solution, and finds the stub project in oslo-incubation.<br>
<br>
2) Just plunk all of this code into oslo-incubation as-is and do all iterating there. That might cause a bit more copying around of code during the simplification process, but would potentially achieve the reusability goal sooner, possibly by a couple of months.<br>

<br>
3) Use pypi. In all honesty we have enough new developers (about half the engineers on this project) coming up to speed with how things work in the OpenStack ecosystem that I'm reluctant to throw that into the mix too.<br>

<br>
What do you all prefer?<br>
</blockquote>
<br>
<br>
I'd personally prefer number 2. Besides the reasons already raised in<br>
this thread we should also add the fact that having it in<br>
oslo-incubator will make it easier for people from other projects to<br>
contribute, review and improve that code.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><div><br></div><div>Exactly. This sounds like a feature we want to live in a common library, but without a currently stable API. That's exactly what the incubator is for.</div>
<div><br></div><div>Doug</div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Dec 3, 2013, at 2:58 PM, Mark McLoughlin <<a>markmc@redhat.com</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 2013-12-03 at 22:44 +0000, Joshua Harlow wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sure sure, let me not make that assumption (can't speak for them), but<br>
even libraries on pypi have to deal with API instability.<br>
</blockquote>
<br>
Yes, they do ... either by my maintaining stability, bumping their major<br>
version number to reflect an incompatible change ... or annoying the<br>
hell out of their users!<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just more of suggesting, might as well bite the bullet (if objects folks<br>
feel ok with this) and just learn to deal with the pypi method for dealing<br>
with API instability (versions, deprecation...). Since code copying around<br>
is just creating a miniature version of the same 'learning experience'<br>
except u lose the other parts (versioning, deprecation, ...) which comes<br>
along with pypi and libraries.<br>
</blockquote>
<br>
Yes, if the maintainers of the API are prepared to deal with the demands<br>
of API stability, publishing the API as a standalone library would be<br>
far more preferable.<br>
<br>
Failing that, oslo-incubator offers a halfway house which sucks, but not<br>
as as much as the alternative - projects copying and pasting each<br>
other's code and evolving their copies independently.<br>
</blockquote></blockquote>
<br>
Agreed. Also, as mentioned above, keeping the code in oslo will bring<br>
more eyeballs to the review, which helps a lot when designing APIs and<br>
seeking for stability.<br>
<br>
Projects throughout OpenStack look for re-usable code in Oslo first -<br>
or at least I think they should - and then elsewhere. Putting things<br>
in oslo-incubator has also a community impact, not just technical<br>
benefits. IMHO.<br>
<br>
FF<br>
<br>
-- <br>
@flaper87<br>
Flavio Percoco<br>
</blockquote>