<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 March 2016 at 07:11, Matthias Runge <span dir="ltr"><<a href="mailto:mrunge@redhat.com" target="_blank">mrunge@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/03/16 11:48, Beth Elwell wrote:<br>> If we will anyway have potential breakage I don’t understand why the<br>
> better solution here would not be to just use the bower and npm tools<br>
> which are standardised for JavaScript and would move Horizon more<br>
> towards using widely recognised tooling from within not just Openstack<br>
> but the wider development community. Back versions always need to be<br>
> supported for a time, however I would add that long term this could end<br>
> up saving time and create a stable longer term solution.<br>
><br>
<br>
</span>I have a few issues with those "package managers":<br>
- downloads are not verified, there is a chance of getting a "bad" download.<br>
- they are pointing to the outside world, like to github etc. While they<br>
appear to work "most of the time", that might not good enough for the gate<br>
- how often have we been blocked by releases of software not managed by<br>
OpenStack? Seriously, that happens quite a few times over a release<br>
cycle, not to mention breakages by releases of our own tools turning out<br>
to block one or the other sub-project</blockquote><div><br></div><div>To be fair to those package managers,  the issues OpenStack has had with releases of libraries breaking things is a result of us either:</div><div><br></div><div>a) not pinning releases (upper-constraints now fixes that for *things that use it*, which isn't everything, sadly) or</div><div>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 :-)</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>     Richard</div></div><br></div><div class="gmail_extra">ps. as for "unverified downloads" ... they're verified precisely as much as pypi packages are, and we install a whole buncha those :-)</div></div>