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.
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
pgp6KLFAs7iWx.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
