This is the mail archive of the
mailing list for the GCC project.
Re: GCC Buildbot
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Paulo Matos <email@example.com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Thu, 21 Sep 2017 23:17:35 +0000
- Subject: Re: GCC Buildbot
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org>
On Thu, 21 Sep 2017, Paulo Matos wrote:
> I totally agree that only if people get involved in checking if there
> were regressions and keeping an eye on what's going on are things going
> to improve. The framework can help a lot here by notifying the right
> people and the mailing list if something gets broken or if there are
> regressions but once the notification is sent someone certainly needs to
> pick it up.
A regression that isn't fixed quickly needs to end up as an appropriately
regression-marked (subject, target milestone) bug in Bugzilla, as that's
what's used to track regressions for release management purposes. And as
far as possible it should be one bug per logical issue, whether it causes
one test FAIL or thousands.
Note: a test result
where there was no previous
on that platform is not generally a regression, although it should still
be fixed to keep test results clean (we want that 0-FAIL expected
baseline...). But it *can* be a regression if e.g.
FAIL: foo (internal compiler error)
as it's not always the case that the test names - the text after "PASS: "
or "FAIL: " - are properly invariant under changes in the results of the
Joseph S. Myers