On Wednesday, December 4, 2013, Flavio Percoco wrote:

> On 04/12/13 01:13 +0000, Adrian Otto wrote:
>> 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.
>> I will remind us that Solum is not currently an incubated project. Should
>> we address this concern now, or during an incubation phase?
> This is not just a Solum issue but a general issue throughout
> OpenStack. The sooner we sort this out, the better.
>> Some approaches for us to consider:
>> 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.
>> 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.
>> 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.
>> 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.
>> What do you all prefer?
> I'd personally prefer number 2. Besides the reasons already raised in
> this thread we should also add the fact that having it in
> oslo-incubator will make it easier for people from other projects to
> contribute, review and improve that code.

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


>> On Dec 3, 2013, at 2:58 PM, Mark McLoughlin <mar...@redhat.com>
>> wrote:
>>  On Tue, 2013-12-03 at 22:44 +0000, Joshua Harlow wrote:
>>>> Sure sure, let me not make that assumption (can't speak for them), but
>>>> even libraries on pypi have to deal with API instability.
>>> Yes, they do ... either by my maintaining stability, bumping their major
>>> version number to reflect an incompatible change ... or annoying the
>>> hell out of their users!
>>>  Just more of suggesting, might as well bite the bullet (if objects folks
>>>> feel ok with this) and just learn to deal with the pypi method for
>>>> dealing
>>>> with API instability (versions, deprecation...). Since code copying
>>>> around
>>>> is just creating a miniature version of the same 'learning experience'
>>>> except u lose the other parts (versioning, deprecation, ...) which comes
>>>> along with pypi and libraries.
>>> Yes, if the maintainers of the API are prepared to deal with the demands
>>> of API stability, publishing the API as a standalone library would be
>>> far more preferable.
>>> Failing that, oslo-incubator offers a halfway house which sucks, but not
>>> as as much as the alternative - projects copying and pasting each
>>> other's code and evolving their copies independently.
> Agreed. Also, as mentioned above, keeping the code in oslo will bring
> more eyeballs to the review, which helps a lot when designing APIs and
> seeking for stability.
> Projects throughout OpenStack look for re-usable code in Oslo first -
> or at least I think they should - and then elsewhere. Putting things
> in oslo-incubator has also a community impact, not just technical
> benefits. IMHO.
> FF
> --
> @flaper87
> Flavio Percoco
OpenStack-dev mailing list

Reply via email to