July 27, 2018 6:59 AM, "Ramana Radhakrishnan" <ramana....@googlemail.com> wrote: > 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: >>> . >>> .. 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
Can-do. I'll reach out to those involved. None of these commits are coorporate sponsored. >> 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. Can-do. The white-space issues definitely need to be corrected. >> >> 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? We have some (limited) space reserved on our core infrastructure for such builders. We also have a global network of physical builders managed by project volunteers and sponsored by Mozilla. (hand-me-downs builders :-)) >> 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) 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? I'd assume when introducing new platform support, some leeway would be provided until the platform could be flagged as stable (or jump up a more "supported" level). Of course, any changes which would present risk to unrelated platforms (Linux, etc) would need increased scrutiny. On a side / unrelated note, we have been upstream in clang / llvm for quite some time... my goals here are to get gcc to the same level of support. > 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 ? +1. It would be nice to have expectations posted. I came into this a little blind based on that article. >>> 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. Yeah, I wasn't 100% on what the best process was here. We have been in upstream autotools for quite a few years... i'll see if this needs to be moved to libtool upstream. -- Alexander von Gluck IV
