[openstack-dev] [Horizon] How do we move forward with xstatic releases?
zigo at debian.org
Thu Mar 17 07:59:03 UTC 2016
On 03/17/2016 07:12 AM, Richard Jones wrote:
> On 13 March 2016 at 07:11, Matthias Runge <mrunge at redhat.com
> <mailto:mrunge at 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
> > 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"
> - 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?
Thomas Goirand (zigo)
More information about the OpenStack-dev