From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4167 invoked by alias); 27 Jul 2018 11:59:08 -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 4146 invoked by uid 89); 27 Jul 2018 11:59:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=South, south X-HELO: mail-ua0-f193.google.com Received: from mail-ua0-f193.google.com (HELO mail-ua0-f193.google.com) (209.85.217.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Jul 2018 11:59:05 +0000 Received: by mail-ua0-f193.google.com with SMTP id r10-v6so3163951uao.1 for ; Fri, 27 Jul 2018 04:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tvWvugTNtuaF0UgsZhpRiNwxZHXLzPcHWeEwg5CqZHc=; b=Fbm5Ph7uPJDnfB2wx/p76XKkannDXtEn5UPKJTHvUsIhQrgCiK0irccrB2LBEqST2K sLCmD3dYM9R1+XNM0+T6vkBQs2eXmysKcs4Dbxq7Hq4w/8Vl+8wTEhNxLhRko8mou+3q Hw1BIAbFqRrJS7wbiz2uEmc0IwPDkv6/7z+19uDJ+V3zCsvwHMZZ3GygTPr4yTKMtIYP hly9qpDSu8DTbvgWE6rXy4mnizBysW7YEsSwQ9OMAVw2Hk5bMXOHMBPXqoqfjEOqglag L8NoWHYrx77qjZCpw9wbcrL76M4UIwl5al+QrNeVaxbZZPH6Xn5MFfduOuxSBghj3h6i 7toQ== MIME-Version: 1.0 Received: by 2002:ab0:6044:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 04:59:03 -0700 (PDT) In-Reply-To: References: <20180717012715.26131-1-kallisti5@unixzen.com> From: Ramana Radhakrishnan Date: Fri, 27 Jul 2018 11:59:00 -0000 Message-ID: Subject: Re: [PATCH] haiku: Initial build support To: Joseph Myers Cc: Alexander von Gluck IV , gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg01714.txt.bz2 On Thu, Jul 26, 2018 at 6:26 PM, Joseph Myers wro= te: > 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=C3=A7ois 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