From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58441 invoked by alias); 26 Jul 2018 17:26:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 58424 invoked by uid 89); 26 Jul 2018 17:26:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=more!, more, foot, postal X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Jul 2018 17:26:15 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-MBX-03.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1fik1k-0001XH-LQ from joseph_myers@mentor.com ; Thu, 26 Jul 2018 10:26:12 -0700 Received: from digraph.polyomino.org.uk (137.202.0.87) by SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 26 Jul 2018 18:26:09 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1fik1g-0000ux-If; Thu, 26 Jul 2018 17:26:08 +0000 Date: Thu, 26 Jul 2018 17:26:00 -0000 From: Joseph Myers To: Alexander von Gluck IV CC: Subject: Re: [PATCH] haiku: Initial build support In-Reply-To: <20180717012715.26131-1-kallisti5@unixzen.com> Message-ID: References: <20180717012715.26131-1-kallisti5@unixzen.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-326391984-1532625968=:25831" X-SW-Source: 2018-07/txt/msg01678.txt.bz2 ---1152306461-326391984-1532625968=:25831 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Content-length: 2625 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. > 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 ---1152306461-326391984-1532625968=:25831--