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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev