On 6/9/20 3:01 PM, Nicolas Mailhot via devel wrote:
Le mardi 09 juin 2020 à 14:56 +0200, Nicolas Mailhot a écrit :
> Le mardi 09 juin 2020 à 14:35 +0200, Vít Ondruch a écrit :
>> The proposal was to optionally disable test. When somebody asked
>> why,
>> the answer was bootstrapping. But we know how to handle
>> bootstrapping.
>> So shouldn't somebody spend time changing the test conditionals to
>> bootstrapping conditionals, because that seems to be the use case?
> One use case is bootstrapping. Another is just getting things to
> build
> till you have the time to investigate if a new test failure is an
> actual problem or upstream being careless as usual. There are
> probably
> other use cases out there
Another fun case: someone broke the dep of a component used in unit
tests. Fixing the component requires rebuilding the dep. Except, the
dep uses the component itself in its own unit tests…
There are boundless possibilities for fun and profit there (well
profit, not so sure actually)
Another common one for me is rapid development in the spec file.
Overall, bootstrapping is definitely a common reason for disabling
tests, but it's not the only one.
Using bootstrapping conditional for non-bootstrapping purposes would be
even more confusing than the status quo.
Therefore people will want to create macros that disable tests. I think
we should follow the example of the bootstrapping macro, and recommend
one macro that disables tests.
Tomas