Open Stack

A couple thoughts (sorry, it's late here):

1. I'll repeat my call for a list (somewhere) of who OpenStack's "downstream stakeholders" are. I'm in favor of our commitment of support and cooperation, but providing openness and insight into who we're offering it to would be awesome.

2. Bundling LESS vs. other means: If you think downstream packagers don't like node... pretty much nobody packages LESS. The recommended way to install LESS is actually with NPM (the Node Package Manager). We could install it that way, but that makes dependency management even more complicated. The important bit is that people need to use a relatively consistent version of LESS, otherwise very hard-to-debug differences in parsing and feature support creep in. So the options became "package the very small, similarly licensed binary" or "make the dependency mess even larger than it has to be".

3. Why node.js/LESS vs. SASS/Ruby...

3a. I wish there was a great solution to this problem in Python. There just isn't right now. So that leaves LESS and SASS as the two best tools out there. Either one introduces a new language.

3b. LESS vs. SASS is partly a matter of preference, and partly a matter of playing nice with previous choices Horizon has made (such as building on top of Twitter's Bootstrap framework) which is written in LESS and allows us to do nice clean imports, extensions, etc. LESS also plays nicely with Django apps such as django-compressor which handles static media asset compression and versioning, and can hook into the LESS compiler to dynamically generate the final files.

3c. Node.js vs. Ruby: Looking out later in this release cycle and into future cycles, there are capabilities that node.js can facilitate which Ruby (or Python for that matter) simply can't. Node.js has proven itself to be stupendously capable in terms of real-time communications and massive parallelism. Node libraries like socket.io are quickly becoming part of the permanent landscape on the web. So while it may seem silly to use node.js just for CSS management here, in the longer term we have the potential to leverage it immensely.

4. LESS for dev, commit compiled files: I veto'd this one in Horizon's discussions. I've played this game being a committer for Django when we tried to maintain both "development" and "production" versions of the admin's javascript files. It was a nightmare trying to do due diligence on contributions to make sure they were always in sync, etc. It's also an added burden on the developers to understand this process and always adhere to updating both files. All in all, not a scenario I support in any way shape or form.

5. Client-side LESS vs. server-side LESS: If it is determined to be an unreasonable burden to make node.js a hard requirement, I will admit we could potentially hack a way to make node.js VERY STRONGLY recommended but optional for those who simply will not/cannot install it. I, personally, would never deploy LESS's client-side compilation code since it's a significantly worse experience, but that's just me. That said, see point 3c for why we'll likely have this discussion again in the future...

Finding the right balance is important here.

All the best,

    - Gabriel



> -----Original Message-----
> From: openstack-bounces+gabriel.hurley=nebula.com at lists.launchpad.net
> [mailto:openstack-
> bounces+gabriel.hurley=nebula.com at lists.launchpad.net] On Behalf Of
> Thierry Carrez
> Sent: Friday, May 25, 2012 1:48 AM
> To: openstack at lists.launchpad.net
> Subject: Re: [Openstack] Nodejs in horizon
> 
> Devin Carlen wrote:
> > -1 to introducing formal processes around this.  This will happen from
> > time to time.  Development may be briefly impacted on other platforms
> > but hindering innovation and telling developers that they are
> > responsible for package availability across every distro is not healthy.
> 
> The PPB actually already ruled that new dependencies *need* to be
> discussed on the mailing-list prior to their introduction, if only so that
> downstream stakeholders learn about it and can work to solve it.
> 
> Like others said, new dependencies impact our whole ecosystem and most
> of the time a small amount of discussion can go a long way in choosing a
> solution that is good for everyone, rather than firefighting after the fact.
> 
> You are not responsible for package availability across every distro, but
> you're responsible for playing as nice with them as you can. That's the
> "Facilitation of downstream distribution" obligation of core projects[1], an
> obligation that the PPB can enforce.
> 
> [1] http://wiki.openstack.org/ProjectTypes
> 
> Regards,
> 
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp