As the former Horizon PTL, I have a great respect for the importance of the 
contributions the distro maintainers/developers make to Horizon and OpenStack 
as a whole. From how many bugs the distros manage to find, to their diligence 
in vetting the software that we as Horizon developers provide, to their overall 
passion for the work they do.

It is interesting to me to see the level to which the distros have not had to 
address this problem before. It shows a significant disconnect between the 
Node/JavaScript community and the distros as a whole (not surprising since 
node.js wasn't packaged on many distros until quite recently). I'm not excited 
to see the OpenStack community leading the charge on resolving packaging issues 
that ought to be settled between the JS community and the distros. Yet, if we 
have to in order to move forward I would urge us to reach out to the NPM 
maintainers, major library maintainers, etc. to try and make decisions that 
will benefit everyone for years to come.

It's also interesting to see how strongly people take sides in this debate... 
who is OpenStack for? How crucial are the distros? Obviously if you work for 
RedHat or Canonical the distros are the end-all; OpenStack has to be packaged. 
Other companies? Opinions vary. Flexibility on this issue is not consistent, as 
has been pointed out already.

Monty and Adam Young have, I think, voiced a good moderate viewpoint, which is 
that the distros are a core part of OpenStack's success and we have to ensure 
that they can package our software, but that the distros also cannot dictate 
the tools we use in order to produce the best possible product. Distros are 
ultimately middle-men, they provide value to their users and they make sure 
more people use the software we produce. We can all agree that we want to 
maximize the number of people we can reach.

So, I propose that a group gets together and defines criteria: we need to 
accept that the Horizon team (and those knowledgeable about web-app 
development) know best what tools they need, and they need to produce such a 
list as a starting point. We then need packagers and maintainers to examine 
that list and evaluate it for problems (non-free software, irresolvable 
dependencies, etc.). They're looking strictly for things which are 
un-packageable, not commenting on the necessity of said software. And we need 
people (thanks, Monty) willing to build new tools to find a way to turn that 
list into something the package maintainers can consume without burdening 
either side.

Make sense?

     - Gabriel

-----Original Message-----
From: Thomas Goirand [] 
Sent: Friday, November 14, 2014 11:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon] the future of angularjs development in 

On 11/14/2014 10:10 PM, Martin Geisler wrote:
>> Of course, I need to run tests. That's a big part of the QA work, and 
>> I
>> > will certainly not give-up on that. You will have a hard time 
>> > convincing anyone within the OpenStack community that it's OK to not run 
>> > unit tests.
> That's not what I said: the OpenStack developers will continue to 
> tests the software. I personally don't think it's the job of the 
> downstream packagers to do this QA work. (It's of course cool to run 
> the tests on the system installed by your packages -- that test run 
> would then install the needed tools using npm and bower and whatnot if 
> that's how the upstream has setup the test framework.)

What happens is that the environment within the distribution, inevitably, will 
be different from the one ran on the gate. There's going to be different 
versions of many components and so on. So it is very important for me to also 
run these unit tests, to make sure that everything continues to work.

Yes, the build-dependencies will pull the same components as pulled by 
npm/bower, though they may be installed in different path, and maybe using 
different versions.

On 11/14/2014 10:21 PM, Jeremy Stanley wrote:> On 2014-11-14 15:10:59
+0100 (+0100), Martin Geisler wrote:
> [...]
> Just to quibble on this particular point... distro packagers are also 
> developers. They often (more often than we'd like, and we do try to 
> find ways to help avoid this where possible) need to carry their own 
> patches to tweak the software to fit their deployment and operation 
> model. Being able to rerun tests in-place with packaged versions of 
> everything including their patches helps them confirm that what they 
> distribute still works as intended. Further, the distro users are well 
> within their rights to modify and respin these packages themselves, 
> and will potentially want to be able to run these tests for the same 
> reasons.
> We distribute our tests as part of our software because our tests
> *are* part of our software.

Exactly! Let me give a few examples...

In Jessie, Nova carries patches so that there is support for Ceph. Until a few 
days, there was still an issue with live migration over NFS. This has just been 
fixed (thanks to Mehdi!), and running unit tests at build time confirmed that.

Another example. Jessie will be released with Icehouse Horizon, but with Django 
1.7. The gate didn't test that, but I did. Most patches landed in Juno, though 
never Icehouse will be tested with Django 1.7 in the gate.
Lucky, my package runs these unit tests and I can confirm that it continues to 
work with Django 1.7 in Jessie.

Hoping these are giving you an insight as why it's *really* important to run 
unit tests at build time for distributions,


Thomas Goirand (zigo)

P.S: I also run tempest tests over a Debian package installation to make sure 
OpenStack is also functional. But that's another story... :)

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to