On Fri, 27 Jul 2018, Alexander von Gluck IV wrote: > >> It's much better for issues to be identified within a day or two of the > >> commit causing them than many months later, possibly only after a release > >> has come out with the issue - but that requires an ongoing commitment to > >> keep monitoring test results, posting them to gcc-testresults and keeping > >> them in good shape. > > This is good information, however, does GCC have docs for this? We are a > small team of open source developers with maybe a few man-hours a month > available to dedicate to gcc maintainership. (no excuses, just trying > to set the expectations)
Well, install.texi documents the use of contrib/test_summary to post test results. I think the documentation is better for one-off requirements for a patch, than for expectations for maintainers on an ongoing basis (in that maintainers would typically have been following development for some time, and so have seen what maintainers of other architectures and OSes do - for example, have seen how AIX people promptly raise issues when a patch breaks things for AIX, which is the sort of thing I'd expect target OS maintainers to do in general). > These steps seem like what's needed on a first-class platform (Linux, OS X, > etc). So the same requirements apply to all new GCC platforms code? Requirements for OS and architecture ports aren't well-defined and seem like a good topic for Cauldron discussion. But generically, it's important that new architecture and OS ports don't get in the way of global changes. This means it's important to have sufficient documentation available for architectures for the use of people doing global changes, that it's valuable to have simulators (with OS images as applicable) with information (e.g. DejaGnu board files) available for people wishing to test on the architecture or OS (or hardware systems available in the GCC Compile Farm, for architectures and OSes for which that works better), and that it's valuable if people can tell at a glance at recent gcc-testresults posts what shape the port is in. And, as a matter of working well with other developers, it's much better to find and point out breakage promptly rather than long after the patch that broke something went in (and, in particular, in the same development stage; if there's a design issue with a patch going in during stage 1 which requires design changes for some architectures or OSes, it's very unhelpful if that's only found much later when trunk is in regression-fixes-only mode for the next release). Also, unmaintained features and unused ports are liable to be removed, and having test results posted is important evidence of whether the port is in good shape or should be considered for removal. -- Joseph S. Myers jos...@codesourcery.com
