On 22/01/14 07:32 -0500, Sean Dague wrote:
On 01/22/2014 05:19 AM, Julien Danjou wrote:On Tue, Jan 21 2014, Joe Gordon wrote:I would like to propose having a integration test job in Oslo incubator that syncs in the code, similar to how we do global requirements.I don't think that would be possible as a voting job, since the point of oslo-incubator is to be able to break the API compatibility.I'm starting to feel like we need to revisit that point. Because what happens now is a chunk of code gets worked off in a corner, possibly randomly changing interfaces, not running unit tests in a way that we know it's multi process safe.
This is not true. If there have been abrupt changes on the interfaces then we failed at keeping backwards compatibility. However, that doesn't mean the API is not considered when reviewing nor that it doesn't matter because the library is incubated. This kind of changes usually get filed on all projects using a specific functionality. For example, https://bugs.launchpad.net/oslo/+bug/1266962 Again, if there have been cases where an API has been changed without even notifying others - either with a good commit message, m-l thread or bug report - then there's definitely something wrong in the process and it should be fixed. Also, I'd expect these errors to be raised as soon as they're noted because they may also affect other projects as well. The above is very different than just saying oslo-incubator is not trustworthy because things get copied around and changes to the libraries are made randomly.
So there ends up being a ton of blind trust in the sync right now. Which is why the syncs are coming slower, and you'll have nova 4 - 6 months behind on many modules, missing a critical bug fix that's buried some where inside a bunch of other interface changes that are expensive. (Not theoretical, I just tripped over this in Dec).
I'm sorry but this is not an excuse to avoid syncing from oslo-incubator. Actually, if things like this can happen, the bigger the gap is the harder it'll be to sync from oslo. My suggestion has always been to do periodic syncs from oslo and keep up to day. Interface changes that *just* break other projects without a good way forward have to be raised here. I know we're talking about incubated libraries that are suppose to change but as mentioned above, we always consider backwards compatibility even on incubated libs because they're on its way to stability and breaking other projects is not fun.
I think we need to graduate things to stable interfaces a lot faster. Realizing that stable just means "have to deprecate to change it". So the interface is still changeable, just requires standard deprecation techniques. Which we are trying to get more python libraries to do anyway, so it would be good if we built up a bunch of best practices here.
Agreed. This is something that we've been working on during Icehouse. We should probably define more clear what's the incubation path of modules that land in oslo-incubator. For example, determine where would they fit, how long should they be around based on their functionality and/or complexity etc. We talked about having a meeting on this matter after I-2. Not sure when it'll happen but it'll be a perfect time to discuss this further. Cheers, FF -- @flaper87 Flavio Percoco
pgpv4mSdRVkCi.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
