This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Basic requirements for supporting OS and machine ports.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Richard Henderson <rth at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, Andreas Schwab <schwab at suse dot de>, Chris Metcalf <cmetcalf at mellanox dot com>, Chung-Lin Tang <chunglin_tang at mentor dot com>, Steven Munroe <sjmunroe at us dot ibm dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, David Miller <davem at davemloft dot net>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, Florian Weimer <fweimer at redhat dot com>, Aurelien Jarno <aurelien at aurel32 dot net>, Adam Conrad <adconrad at 0c3 dot net>
- Date: Wed, 19 Apr 2017 15:15:26 +0000
- Subject: Re: Basic requirements for supporting OS and machine ports.
- Authentication-results: sourceware.org; auth=none
- References: <c501b05e-3ae1-5bc8-b5a7-b6c2dabb98bc@redhat.com>
On Tue, 18 Apr 2017, Carlos O'Donell wrote:
> (a) If your OS and machine port has build-many-glibcs.py support then all
> maintainers will strive to ensure that their changes do not break those
> OS and machine combinations supported by the script, and will work to
> correct any such past breakage.
Note that where there are pre-existing testsuite failures / testsuite
build failures (ia64; microblaze; also sh when using GCC trunk, because of
GCC bugs 78459, 78460; hppa before the build broke), it won't be
immediately visible from a build-many-glibcs.py run that *more* test
failures appeared (although examination of the logs will show exactly what
failures there were, unless the testsuite failed to build part way
through).
> (b) If your OS and machine port have a buildbot slave, then all maintainers
> will strive to ensure that their changes do not introduce breakage that
> shows up on those buildbots, and will work to correct any such breakage.
Buildbots don't provide a way for people to test their patches on those
buildbots. Also, I'm not aware of anyone monitoring the bots for
regressions, they don't generally have a clean state of expected results
at present, and they still have the mysterious "make[1]: *** [tests] Error
1" at the end of the test run with no previous errors reported that no-one
has tracked down (I've suggested a bot owner should set it up to run make
with appropriate --debug options and study the output to try to find more
information about the cause). So I don't think buildbot is ready for any
such expectations on maintainers.
(We also don't have a way for buildbots to send test results to
libc-testresults, but that would be a peripheral issue if someone were
monitoring the results for regressions and they actually reliably produced
results for each testsuite run instead of mysterious errors.)
--
Joseph S. Myers
joseph@codesourcery.com