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 [mailto:[email protected]]
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
Horizon
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,
Cheers,
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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
