[openstack-dev] [Horizon] How do we move forward with xstatic releases?
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
>> 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).
They are a *very bad* standard which doesn't work at all with downstream
(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.
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
can't use it.
Thomas Goirand (zigo)
More information about the OpenStack-dev