From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26648 invoked by alias); 22 Jan 2020 16:28:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 26605 invoked by uid 89); 22 Jan 2020 16:28:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.0 required=5.0 tests=AWL,BAYES_00,KAM_MANYTO,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=HX-Languages-Length:2983, H*i:sk:mpty2tz, H*f:sk:mpty2tz, H*MI:sk:mpty2tz X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Jan 2020 16:28:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579710526; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ljY+stbWa+X27aPi6PVCCcoufT6iVmhzzdZvie6v2Z4=; b=dILn3y8C6NnT1ws3sKN+GTvkkX4Stql6LtVGnhpg2lnP3skZ1ugdH2pO6AVRhV0vaqJTMe Llea9Zr6TdoaHFKXMjFplH3XvVmEU7+GY5EYurhiph8XqKasS9blsVvl7CDT6+Hn2VPYDj JKMCOtA/G8YIlxytmJIpuGEtFrPkCYY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-178-7m4V_QRINNS1lrwst21aiw-1; Wed, 22 Jan 2020 11:28:45 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DE1DD800D41; Wed, 22 Jan 2020 16:28:43 +0000 (UTC) Received: from redhat.com (unknown [10.20.4.137]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F1B2D19C69; Wed, 22 Jan 2020 16:28:42 +0000 (UTC) Date: Wed, 22 Jan 2020 17:45:00 -0000 From: Marek Polacek To: "Richard Earnshaw (lists)" , Jason Merrill , Jakub Jelinek , Gerald Pfeifer , gcc-patches@gcc.gnu.org, GCC Development , richard.sandiford@arm.com Subject: Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions Message-ID: <20200122162841.GV31864@redhat.com> References: <353faf3e-bf43-eb4d-542d-45a53dce77b2@arm.com> <20200121150440.GX10088@tucnak> <20200121153902.GY10088@tucnak> <4d99536c-c1af-b4ea-17b0-23b44a3bf8b7@arm.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2020-01/txt/msg00402.txt.bz2 On Wed, Jan 22, 2020 at 04:05:37PM +0000, Richard Sandiford wrote: > "Richard Earnshaw (lists)" writes: > > On 21/01/2020 17:20, Jason Merrill wrote: > >> On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: > >>> On 21/01/2020 15:39, Jakub Jelinek wrote: > >>>> On Tue, Jan 21, 2020 at 03:33:22PM +0000, Richard Earnshaw (lists)=20 > >>>> wrote: > >>>>>> Some examples would be useful I'd say, e.g. it is unclear in what= =20 > >>>>>> way you > >>>>>> want the PR number to be appended, shall it be > >>>>>> something: whatever words describe it PR12345 > >>>>>> or > >>>>>> something: whatever words describe it (PR12345) > >>>>>> or > >>>>>> something: whatever words describe it: PR12345 > >>>>>> or > >>>>>> something: whatever words describe it [PR12345] > >>>>>> or something else? > >>>>> > >>>>> Glibc use "[BZ #nnnn]" - obviously BZ becomes PR, but after that,=20 > >>>>> I'm not > >>>>> too worried.=A0 I'd be happy with [PR #nnnn], but if folk want=20 > >>>>> something else, > >>>>> please say so quickly... > >>>> > >>>> [PR 12345] or [PR #12345] is bad, because the bugzilla won't=20 > >>>> underline it, > >>>> it needs to be either PR12345 word, or PR component/12345 . > >>> > >>> ok, lets go with [PRnnnn] then. > >>=20 > >> Doesn't this use of [] have the same problem with git am? > > > > No, because only 'leading' [] blocks are removed - git mailinfo --help > > > >>=20 > >> My summaries are often describing the bug I'm fixing, i.e. > >>=20 > >> [PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs. > >>=20 > >> which is also the first line of my ChangeLog entry.=A0 I think you are= =20 > >> proposing > >>=20 > >> [COMMITTED] c++: Fix anon-namespace reference temp clash between TUs=20 > >> (PR91476) > >>=20 > >> which can no longer be shared with the ChangeLog. > >>=20 > > > > I was trying to unify this with glibc. They specify the bug number at= =20 > > the end of the line. > > > > We can diverge if it's generally felt to be important, but details like= =20 > > this create needless friction for folk working in both communities. >=20 > +1 for "component: Summary [PRnnnnn]" FWIW. >=20 > PR bz-component/nnnnn works well for C++. The problem is that so many > other PRs come under tree-optimization and rtl-optimization, which > eat up a lot of subject line characters without narrowing things down > very much. "cselib: ... [PRnnnnn]" is both shorter and more descriptive > than "PR rtl-optimization/nnnnn - ....", etc. Yeah, the cselib version definitely looks preferable to me. What if a patch touches more than just the C++ FE, do we want "c,c++:"? Though kernel uses net: sched: act_ctinfo: fix memory leak locking/rwsem: Fix kernel crash when spinning on RWSEM_OWNER_UNKNOWN If a patch touches various spots in the optimizers, maybe we can just go with "tree-opt:" or "rtl:"? Further, I suppose multiple PRs fixed by a single patch would look like: c++: Implement DR 666 [PR57, PR12345] Marek