This is the mail archive of the
mailing list for the GDB project.
Re: automated testing comment [Re: time to workaround libc/13097 in fsf gdb?]
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: <gdb-patches at sourceware dot org>
- Date: Tue, 23 Sep 2014 11:16:04 -0400
- Subject: Re: automated testing comment [Re: time to workaround libc/13097 in fsf gdb?]
- Authentication-results: sourceware.org; auth=none
- References: <5411CFAE dot 7040805 at redhat dot com> <20140912115452 dot GA5626 at host2 dot jankratochvil dot net> <5412E3AC dot 80203 at redhat dot com> <20140912123320 dot GA8704 at host2 dot jankratochvil dot net> <5412EB1F dot 40309 at redhat dot com> <20140917201049 dot GA22880 at host2 dot jankratochvil dot net> <541C3FCF dot 4000400 at redhat dot com> <541C409E dot 6010408 at redhat dot com> <20140920213033 dot GA6255 at host2 dot jankratochvil dot net> <541F2311 dot 1040404 at redhat dot com> <20140923105855 dot GA10164 at host2 dot jankratochvil dot net> <54216860 dot 7060008 at redhat dot com>
On 2014-09-23 08:32 AM, Pedro Alves wrote:
>> And sure deploying automated testing with the current GDB testsuite as is
>> would not work now automatically as the testsuite has fuzzy results.
> We should be able to filter those out though. Of course ideally we'd
> just fix them to not be fuzzy...
If we adopt automated testing as part of the process and those fuzzy tests are
in the way, it will help identify them and it will give some a motivation to fix
What is bugging me is also the failing test cases in master. In order to make
Jenkins (or similar) useful, you need a baseline where everything is green.
Otherwise all patches that will get tested will fail and it will be difficult
to weed out the actually failing patches from the good ones.
Unless there is actually a way to make a pass/fail/unresolved "diff" that
compares the patch's results to those of the latest master commit's results.
Last time I checked, it didn't seem obvious.