Re: [PATCH] haiku: Initial build support

[Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>]

On Thu, Jul 26, 2018 at 6:26 PM, Joseph Myers <joseph@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
> joseph@codesourcery.com