[openstack-dev] [Horizon] How do we move forward with xstatic releases?

Thomas Goirand zigo at debian.org
Mon Mar 14 00:02:13 UTC 2016

On 03/10/2016 11:48 AM, Beth Elwell wrote:
>> On 10 Mar 2016, at 07:46, Richard Jones <r1chardj0n3s at gmail.com
>> <mailto:r1chardj0n3s at gmail.com>> wrote:
>>     It has been mentioned, xstatic packages can block the gate. We
>>     currently
>>     control xstatic package releases, thus we can roll back, if something
>>     goes wrong.
>>     If we're pulling directly with npm/bower, someone from the outside can
>>     break us. We already have the situation with pypi packages.
>>     With proper packages, we could even use the gate to release those
>>     packages and thus verify, we're not breaking anyone.
>> We're going to have potential breakage (gate breakage, in the
>> integrated tests) any time we release a package (regardless of release
>> mechanism) and have to update two separate repositories resulting in
>> out-of-sync version specification and expectation (ie.
>> upper-constraints specification and Horizon's code expectation) as
>> described in my OP. The only solution that we're aware of is to
>> synchronise updating those two things, through one of the mechanisms
>> proposed so far (or possibly through a mechanism not yet proposed.)
> 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

We control the breakages, and we're trying to find a solution (if you
didn't notice, many where proposed in this thread).

> which are standardised for JavaScript

They are a *very bad* standard which doesn't work at all with downstream
distributions. Unless someone adds a system wide registry for javascript
(the say way that if you apt-get a Python package, pip wont download
it), then we can't use it.

> and would move Horizon more
> towards using widely recognised tooling

Recognized by who? Certainly not downstream distributions. This is a

> from within not just Openstack
> but the wider development community.

What community are you talking about? That JavaScript community which
breaks APIs every 2 weeks? Please re-read this:


and especially the part:
"Why we use XStatic"

We have every few months some Horizon contributors advocating for
pushing toward this direction, however, none have yet shown a way to
solve what Xstatic does. Until this is done, please refrain from writing:

"hey, everyone uses X, so let's do the same"

without valid technical argumentation.

Yes, using npm / bower / gulp / you-name-it, may make your Horizon
contributor life easier. But that's *not* the only thing to consider.

> 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.

Long term, I would like to see more contributions to the upstream
JavaScript tooling to make it behave reasonably. Until this is done, we
can't use it.


Thomas Goirand (zigo)

More information about the OpenStack-dev mailing list