Re: [libvirt] [PATCH] docs: document that C & Python are the preferred languages
On Tue, Oct 01, 2019 at 10:27:33AM +0100, Daniel P. Berrangé wrote:
On Mon, Sep 30, 2019 at 08:50:51PM +0000, Jim Fehlig wrote:
> On 9/23/19 7:52 AM, Daniel P. Berrangé wrote:
> > On Thu, Sep 05, 2019 at 06:15:04PM +0100, Daniel P. Berrangé wrote:
> >> On Thu, Sep 05, 2019 at 12:30:27PM -0400, Laine Stump wrote:
> >>> (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.)
> >>
> >> I believe they are run by the Red Hat virt QE team, as I ave
> >> got bug reports against the Perl libvirt bindings, where the
> >> reproducer is a TCK script.
>
> Sorry for jumping in late, but I also run TCK regularly and agree that it does
> find real bugs on occasion. I've submitted several patches over the years
fixing
> bugs found by TCK, and a sprinkling of patches to TCK itself. I admit the perl
> requirement has deterred writing new tests.
Thanks for the feedback. To summarize my thoughts on what we do with
the TCK:
- Replace the test execution harness with tappy, which is a python
impl that can consume TAP format
So, currently I'm working on fixing the last bits on TCK failures to enable
running it upstream on ci.centos.org and continue from there. I think there was
a thread somewhere (may have been an internal one), where we also considered
the usage of plain avocado as the execution and harness engine as it not only
provides TAP support, but also other results reporting formats as well as
having support for test matrices by using a multiplexer. Is that idea out of
question, as I'm willing to (and already spending time on) to make progress in
this area.
- Add supporting code to facilitate writing new scripts in python
- New tests should then be written in Python
- Existing tests can remain in Perl indefinitely
- Existing Perl tests can be ported to Python as desired.
Erik