Adam Young wrote:
On 11/09/2015 09:46 AM, Thierry Carrez wrote:
Sean Dague wrote:
I do wonder what the cause of varying quality is in the distros. I do
understand that some distros aren't licensing the test suite. But they
are all building from the same upstream.
Except that they all use significant (and different) patchsets on top of
that "same upstream". Ubuntu for example currently carries 69 patches on
top of OpenJDK 7 source.
I can't speak explicitly for Ubuntu, but this is the norm for anything
from a Distro; they pick a version for the LTS release and then choose
the patches to continue to apply to that version. Red Hat does this with
OpenStack, as well as OpenJDK and the Kernel. The same is true of
Python, too.
+1
If you haven't looked at how many patches some RHEL packages have you
might want to, 69 patches is nothing from what I have seen...
For example (rpm detailing program here):
https://gist.github.com/harlowja/9b443d1af13a57a48f4f
$ python rpm-info.py
"http://vault.centos.org/6.5/os/Source/SPackages/libvirt-0.10.2-29.el6.src.rpm";
http://vault.centos.org/6.5/os/Source/SPackages/qemu-kvm-0.12.1.2-2.415.el6.src.rpm
--------------------------
Getting details for 2 rpms
--------------------------
Downloading:
http://vault.centos.org/6.5/os/Source/SPackages/libvirt-0.10.2-29.el6.src.rpm
[################################] 22378/22378 - 00:00:02
Downloading:
http://vault.centos.org/6.5/os/Source/SPackages/qemu-kvm-0.12.1.2-2.415.el6.src.rpm
[################################] 9601/9601 - 00:00:01
-------------
Gathered info
-------------
+-------------------------------------+-----------+
| Filename | Patches |
+=====================================+===========+
| libvirt-0.10.2-29.el6.src.rpm | 538 |
+-------------------------------------+-----------+
| qemu-kvm-0.12.1.2-2.415.el6.src.rpm | 3497 |
+-------------------------------------+-----------+
IMHO at least java has a TCK, does libvirt have one or KVM..., because
with the number of patches listed above, who knows exactly what version
of libvirt or qemu is really running (the version number IMHO makes less
sense when there are 3400+ patches).
Java is a different language than Python. I understand that many people
dislike it for verbosity, its proprietary history, and so forth. But
with the OpenJDK, we have the same rules for releasing it as we do for
Python, Ruby, Perl, Common Lisp, COBOL, Fortran, Ada, C++, and Go. Hope
to add Rust to that litany, soon, too.
I personally like Java, but feel like we should focus on limiting the
number of languages we need to understand in order to Do OpenStack
development. I personally find Python annoying since I like type safety,
but I've come to understand it. The fact that Puppet already makes us
jump to Ruby already makes it hard. One reason I prefer the recent
inroads by Ansible is that it lets me stick to a single language for the
business logic. It has nothing to do with the relative technical merits
of Python versus Ruby.
For the most part, the third party tools we've had to integrate have
been native apps, at least on the Keystone side; LDAP, Database, and
Memcache are all native for performance reasons. The Dogpile abstraction
would allow us to do Cassandra, but that never materialized.
As an example: I've been pointing out that we should be defaulting to
Dogtag for Certificates. Dogtag is a Java server app. This is due to its
long history as an OpenSource CA with very demanding deployments
hardening it. However, I don't think it should be the CA abstraction for
OpenStack. I would recommend a Native tool, Certmonger, with a mechanism
that can be extended by Python. This would allow for a native python
implementation, or any other that actual deployments would chose to use,
as the CA implementation.
Let's keep the toolchain understandable, but for the right reasons.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
