On 9/5/19 10:51 AM, Andrea Bolognani wrote:
On Thu, 2019-09-05 at 15:42 +0100, Daniel P. Berrangé wrote:
On Thu, Sep 05, 2019 at 04:22:17PM +0200, Andrea Bolognani wrote:
On Thu, 2019-09-05 at 12:42 +0100, Daniel P. Berrangé wrote:
+ The libvirt repository makes use of a large number of programming
+ languages. There is a general desire to phase out some of the
+ existing languages used to reduce the knowledge burden on
+ developers, and facilitate introduction of new languages in
+ the future.
Reducing the number of languages used by the project and facilitating
the introduction of more languages seem to be contrasting goals.
Accordingly, I would leave out the last part of the sentence.
That are actually directly related. The aim is to eliminate some
existing languages, so that when we add more languages, we've not
increased the overall burden.
I think the fact that we want to add more languages only makes
reducing the number of languages more pressing than it would be
otherwise, but reducing the cognitive load for contributors is a
worthy goal in its own right and alone would be enough to justify
standardizing on Python in my opinion. So I'd still prefer it if
you dropped that last part of the sentence, but I won't insist
further if you're adamant that you want to keep it.
Maybe part of the reason he's saying that is so that the statement can't
be used in the future as an argument against adding a new language?
How would you feel about something like:
"reduce the knowledge burden for old/lame languages on developers and make room in their brains for a more painless introduction of new/cool languages into the codebase in the future."
(BTW, what does the removal of perl from libvirt say about continued use of perl for libvirt-tck? There are a lot of useful tests in there that find real bugs, but they tend to languish (both in use and in enhancements) because nobody wants to do anything with perl (or with the big shell scripts that do the nwfilter testing). It would be nice if the tests were all in a language that was more accessible, but they're kind of married to the perl TAP module (and besides, who wants to spend time rewriting a bunch of test scripts when they already work?). This is mostly a moot point, because I think hardly anyone runs the libvirt-tck tests anymore, which is too bad because it has historically caught some regressions that no other testing framework did.)
+ <li>C - for the main libvirt codebase. Dialect supported by
+ GCC/CLang only.</li>
+ <li>Python - for supporting build scripts / tools. Code must
+ run with both version 2.7 and 3.x at this time.</li>
Instead of esplicitly singling out 2.7 and 3.x, I would just say that
for both C and Python there it is required to support all platforms
listed in "platforms.html".
I think its important to call our both python versions explicitly
as most distros support both versions in one way or another, so
its not clear from platforms.html that we want to support both.
Adopting Meson will eventually force the matter as that requires
python 3, so we'll have to drop py2 at that point.
Alright.
+ <p>
+ Languages that should not be used for any new contributions.
s/contributions./contributions:/
If you fix this one:
Reviewed-by: Andrea Bolognani <abologna@xxxxxxxxxx>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
