This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] haiku: Initial build support

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


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 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 ?


>> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]