Re: [PATCH 1/5] sparse: Show expected vs. actual output on test failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 26, 2011 at 2:10 AM, Pekka Enberg <penberg@xxxxxxxxxx> wrote:
> Chris, the patch you committed is different from mine:
>
> http://git.kernel.org/?p=devel/sparse/chrisl/sparse.git;a=commitdiff;h=a7a00d5108c36b8baaf54814aa1f42583dabc754
>
> Your patch now makes the runner verbose for "known to fail" tests
> which is definitely not something we should do. If someone tagged
> the test as "known to fail", we should treat it just like we treat
> passed test cases.

That is intentional. I haven't seen you reply on my comment so I take
the liberty to change it. I do want to see the "known to fail" test
case.

>
> The whole point of my patch was to make "make check" pinpoint
> *unexpected* breakage so that anyone who bothers to do "make check"
> on their patches can never cause regressions.

How to you know your new patch did not break "known to fail" test
case in a different way than originally? It could be regression as well.

You can diff the aggregate output of "make check" before and after
the new patch to see if the new patch affect any test case at all.
That is better than blindly skip the "known to fail" test case.

Yes, I have a different usage case in mind. I want to look at what currently
breaks. In the long run, hopefully we fix all the known issues so this
wouldn't be any issue at all.

You can submit a patch to add a config for it if you are so insist on
the "I don't care about already broken test cases" usage case.
To me, diff the "make check" output is straightly better.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux