Ack, please don't keep on adding on to the copy around stuff scheme. Pleaaaase :-)
Is the devstack dependency list complete, when I created the anvil one, I found more than one hole... Also the devstack one is in a micro-format, maybe we can move to say, YAML? How about hosting these requires on some website (with versions there)? Github already provides this for the anvil dependency list, maybe that (or something) similar is sufficent? On 7/2/12 3:40 PM, "Monty Taylor" <mord...@inaugust.com> wrote: Hey all! One of the tasks from the last ODS was to implement a single global dependency list. Turns out the more you think about it, the more important it is... because of the way we use devstack as part of the gate, we actually _currently_ have a de facto global dependency list, it's just not declared anywhere. (oops) Anyway - the original thought was to put the depends in openstack-common. We'd use update.py to copy the depends in to the project, so that projects could align on their own timeframe. Additionally, we'd make the copy only copy in the versions from openstack-common for package that were already listed in the target project, so that we wouldn't add django to python-swiftclient, for instance. The mechanics of that all work and are ready - but then bcwaldon pointed out that it didn't make a ton of sense for them to go in openstack-common, since that has its own lifecycle and is a place for common code to go - not just a catch all place. To that end, I took the code we had written for the update logic and put it, along with the depends lists, into its own repo. I think we're ready to start actually moving forward with it - but we've run up against the hardest problem we every have: naming openstack-depends already got vetoed on IRC because it makes people think of adult diapers. I'm proposing openstack-requires, since the files we're talking about are actually python requirements files. Any objections? We've also been discussing an idea that we could write some gating tests that are only run against milestone-proposed branches that would verify that the requires files in a given project match the versions in openstack-requires - that way there is some lee-way throughout the cycle, but the expectation is that by release time the requires files will be brought in line with the rest of the project. (it's an option if people find that useful - certainly not required) Finally, as an added bonus to this approach, once we have the list and we're even mostly aligned on it, since a library version would need to be in openstack-requires before it hits a project, we can use it as the main basis for our pypi mirror and turn off the upstream pypi source from our jenkins slaves. This would remove the last of the ephemeral build errors that are due to upstream network timeouts. I'm sure everyone will be pleased about that. Anyway - I think general buy in on at _least_ the name openstack-requires will let us move forward with the next step. After that point, it'll all be normal code reviews. Monty _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp