On Thu, Jul 26, 2018 at 6:26 PM, Joseph Myers <jos...@codesourcery.com> wrote: > On Mon, 16 Jul 2018, Alexander von Gluck IV wrote: > >> * We have been dragging these around since gcc 4.x. >> * Some tweaks will likely be needed, but this gets our foot >> in the door. >> >> Authors: >> Fredrik Holmqvist >> Jerome Duval >> Augustin Cavalier >> François Revol >> Simon South >> Jessica Hamilton >> Ithamar R. Adema >> Oliver Tappe >> Jonathan Schleifer >> .. and maybe more! > > Before this can be reviewed, we'll need copyright assignments (with > employer disclaimers where applicable) on file at the FSF from everyone > who contributed a legally significant amount of code (more than around 15 > lines). Without those, reviewers can't safely look at the changes in > detail. > > https://gcc.gnu.org/contribute.html > > https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future > > Then, please make sure that only substantive changes are included - that > there are no diff lines that are purely changing trailing whitespace in > existing code, for example. Please ensure that all copyright and license > notices follow current standards (which means using ranges of years ending > in 2018, GPLv3 notices and a URL not an FSF postal address). For changes > to existing code, especially, please make sure to include sufficient > rationale in the patch submission to explain those changes, why they are > needed and the approach taken to them. > > For new target OS support, I'd expect details to be provided of the test > results on that OS for the various architectures supported by GCC. Are > you planning, if the support is accepted in GCC, to maintain a bot that > keeps running the GCC testsuite for GCC mainline for this OS for the > various target architectures supported, at least daily or thereabouts, and > posts the results to the gcc-testresults list, and to keep monitoring the > test results and fixing OS-specific issues that show up? 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.
Joseph, A lot of such information seems to come out from a number of reviewers only during patch review from new contributors. Would you mind improving https://gcc.gnu.org/contribute.html and especially around "Testing patches" or start something like the glibc contribution checklist on the wiki that actually makes a lot of this easy to find rather than searching in mailing list archives for new contributors ? regards Ramana > >> diff --git a/libtool.m4 b/libtool.m4 > > If this an exact backport of a change from upstream libtool git? If so, > please give the commit reference. If not, give the URL of the submission > to upstream libtool. We don't want local libtool changes that aren't > backports or at least proposed upstream without objections, to avoid > making future updates from upstream libtool harder. > > -- > Joseph S. Myers > jos...@codesourcery.com
