On 2015-01-22 16:06:55 -0500 (-0500), Matthew Farina wrote: [...] > When there is an update to our requirements, such as the recent > version increment in the version of angular used, a new package > version doesn't automatically show up as evident from that list. > How would that process be kicked off so we don't end up with a > missing dependency? Does that have to wait for a release cycle?
I don't want to speak for the distro package maintainers, but from what I've seen they generally wait until close enough to an integrated release that they can be pretty sure the requirements are close to frozen, so as not to waste effort packaging things which will end up not being used. > Many of the xstatic packages are maintained by the OpenStack > community. Just see the list in stackforge > (https://github.com/stackforge/?query=xstatic). Right now we need > to update the xstatic package ourselves and then start using it. > It also feels a little odd to maintain xstatic packages for pypi > that we don't consume that way. I assume (perhaps incorrectly?) that we do use those in CI jobs, so that we can download the things a given project needs in an automated fashion--for us handling pip requirements lists is a solved problem (well, for some definitions of solved at least). > This appears to affect the testing setup as well. When we start to > use a new version of a JavaScript dependency no package will exist > for it. I believe this would mean the testing environment needs to > use the development setup, in the proposal, of bower. IIRC, bower > goes out to the Internet and there isn't a mirror of packages > (just a mirror of the registry). That means we'll loose the > ability to run testing installs from local mirrors for these > dependencies. I imagine a solution has been thought of for this. > Can you share any details? I am not aware of what the solution for this would be, but it will be a show-stopper for the plan and so I (Infra hat on) would expect the horizon developers to come up with an implementation which solves that. Perhaps some routine to retrieve and pre-cache the necessary files like we do with a lot of the random files devstack uses, and then run that during image build time so that it's already present on the filesystems of the machines which will run the jobs needing it? -- Jeremy Stanley __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev