On 03/17/2016 07:12 AM, Richard Jones wrote: > On 13 March 2016 at 07:11, Matthias Runge <mru...@redhat.com > <mailto:mru...@redhat.com>> wrote: > > On 10/03/16 11:48, Beth Elwell wrote: > > If we will anyway have potential breakage I don’t understand why the > > better solution here would not be to just use the bower and npm tools > > which are standardised for JavaScript and would move Horizon more > > towards using widely recognised tooling from within not just Openstack > > but the wider development community. Back versions always need to be > > supported for a time, however I would add that long term this could end > > up saving time and create a stable longer term solution. > > > > I have a few issues with those "package managers": > - downloads are not verified, there is a chance of getting a "bad" > download. > - they are pointing to the outside world, like to github etc. While they > appear to work "most of the time", that might not good enough for > the gate > - how often have we been blocked by releases of software not managed by > OpenStack? Seriously, that happens quite a few times over a release > cycle, not to mention breakages by releases of our own tools turning out > to block one or the other sub-project > > > To be fair to those package managers, the issues OpenStack has had with > releases of libraries breaking things is a result of us either: > > a) not pinning releases (upper-constraints now fixes that for *things > that use it*, which isn't everything, sadly) or > b) the system that tests upper-constraints changes not having broad > enough testing across OpenStack for us to notice when a new library > release breaks things. I would like to increase the inclusion of > Horizon's test suite in the constraints testing for this reason. At > least, it's on my TODO :-) > > Horizon, for example, currently does *not* use the upper-constraints > pinning in its test suite or installation, so we're vulnerable to, say, > a python-*client release that's not compatible. I have a patch in the > works to address this, but it kinda depends on us moving over from > run_tests.sh to tox, which is definitely something to wait until N for.
Thanks for this work. I'm looking forward to it. Do you also have in the pipe to stop using nose / python -m coverage, and switch to testr? Cheers, Thomas Goirand (zigo) __________________________________________________________________________ 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
