Open Stack

On 11/13/2014 08:05 PM, Radomir Dopieralski wrote:
> On 11/11/14 08:02, Richard Jones wrote:
> 
> [...]
> 
>> There were some discussions around tooling. We're using xstatic to
>> manage 3rd party components, but there's a lot missing from that
>> environment. I hesitate to add supporting xstatic components on to the
>> already large pile of work we have to do, so would recommend we switch
>> to managing those components with bower instead. For reference the list
>> of 3rd party components I used in angboard* (which is really only a
>> teensy fraction of the total application we'd end up with, so this
>> components list is probably reduced):
> 
> [...]
> 
>> Just looking at PyPI, it looks like only a few of those are in xstatic,
>> and those are out of date.
> 
> There is a very good reason why we only have a few external JavaScript
> libraries, and why they are in those versions.
> 
> You see, we are not developing Horizon for our own enjoyment, or to
> install it at our own webserver and be done with it. What we write has
> to be then packaged for different Linux distributions by the packagers.
> Those packagers have very little wiggle room with respect to how they
> can package it all, and what they can include.
> 
> In particular, libraries should get packaged separately, so that they
> can upgrade them and apply security patches and so on. Before we used
> xstatic, they have to go through the sources of Horizon file by file,
> and replace all of our bundled files with symlinks to what is provided
> in their distribution. Obviously that was laborious and introduced bugs
> when the versions of libraries didn't match.
> 
> So now we have the xstatic system. That means, that the libraries are
> explicitly listed, with their minimum and maximum version numbers, and
> it's easy to make a "dummy" xstatic package that just points at some
> other location of the static files. This simplifies the work of the
> packagers.
> 
> But the real advantage of using the xstatic packages is that in order to
> add them to Horizon, you need to add them to the global-requirements
> list, which is being watched and approved by the packagers themselves.
> That means, that when you try to introduce a new library, or a version
> of an old library, that is for some reason problematic for any of the
> distributions (due to licensing issues, due to them needing to remain at
> an older version, etc.), they get to veto it and you have a chance of
> resolving the problem early, not dropping it at the last moment on the
> packagers.
> 
> Going back to the versions of the xstatic packages that we use, they are
> so old for a reason. Those are the newest versions that are available
> with reasonable effort in the distributions for which we make Horizon.
> 
> If you want to replace this system with anything else, please keep in
> contact with the packagers to make sure that the resulting process makes
> sense and is acceptable for them.

Thanks a lot for all you wrote above. I 100% agree with it, and you
wrote it better than I would have. Also, I'd like to thank you for the
work we did together during the Juno cycle. Interactions and
communication on IRC were great. I just hope this continues for Kilo, on
the line of what you wrote above.

Cheers,

Thomas Goirand (zigo)