Re: Revisiting the migration path to Kyua

[Julio Merino <jmmv%outlook.com@localhost>]

On Feb 15, 2014, at 12:12 , Andreas Gustafsson <gson%gson.org@localhost> wrote:

> 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?

The way things are now (and the way things were last year), when you set 
MKKYUA=yes, atf-run and atf-report get replaced by shell scripts that invoke 
kyua underneath.  The CLI of these scripts is compatible with the real ATF 
tools, but the semantics of their execution differ.  This is why flipping the 
flag on your system showed some differences.

With my new proposal, setting MKKYUA=yes would have no effect on atf-run nor 
atf-report at all.  These tools would continue to be the "real ATF tools" and, 
to invoke Kyua, you'd need to execute kyua explicitly.  Users would then need 
to manually switch their invocations to use kyua(1) instead, and we'd work on 
cleaning up any rough edges in the tool without affecting atf-* nor rushing to 
replace them.