Open Stack

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" <mordred at 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 at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120702/1483f052/attachment.html>