Re: Revisiting the migration path to Kyua

[Andreas Gustafsson <gson%gson.org@localhost>]

Julio,

You wrote:
> Proposal: make MKKYUA=yes NOT replace atf-run and atf-report with
> compatibility wrappers.  Instead, allow both kyua and
> atf-run/atf-report to coexist in the same installation, and then set
> MKKYUA=yes by default.  (We'd probably kill the import of
> kyua-atf-compat along the way as well; yay, less code.)
> 
> This would allow 1) the continuous testing machines to work just
> fine without any changes to them

I don't think that's quite true.  I followed your suggestion last year
of making the "anita test" command run kyua if the system was built
with MKKYUA=yes or atf-run + atf-report otherwise, and if I understand
your new proposal correctly, because it involves setting MKKYUA to
"yes", it would cause the continuous testing machines to run the kyua
tests but not the ATF tests.  Would we not want them to either continue
running the ATF tests, or to run both of them?

> and 2) it would also allow end users to start playing with the new
> tools without the need to rebuild the system.  We'd then more easily
> and progressively evaluate the change.

Has there been any progress on the issue of the kyua output needing
much more disk space than the ATF output does?

How much disk space and how many inodes per test run will it take to
store the kyua output initially, if your proposal is implemented but
assuming no additional kyua tests have yet been created or ported over
from the ATF side?
-- 
Andreas Gustafsson, gson%gson.org@localhost