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 for. Doug > > >> 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 OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev