From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id DB82338618DF for ; Wed, 7 Jul 2021 21:53:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DB82338618DF Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-184-nD7D_x0dN4qiN38jbxHn2A-1; Wed, 07 Jul 2021 17:53:38 -0400 X-MC-Unique: nD7D_x0dN4qiN38jbxHn2A-1 Received: by mail-qk1-f197.google.com with SMTP id i3-20020a05620a1503b02903b2ffa0a87fso2463746qkk.18 for ; Wed, 07 Jul 2021 14:53:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=YFoZZ9Z0QaclRvniqLaiyO2EFflVU+WaaF4R1dS3y1I=; b=dD2PKurEP2zZJvDfiSh9g/WYDdKQe1ci8MigSsCrkbnj8tnSJHfbQ3E9crxKlNb73W JzJp6pqzPSuJt4h/dth/tYUk0TIh+xOO2uhDWNOYlug4VFQJxSg+hYRFsWs4ocXoGRSe ibr+G8aKzG3IGnFTUAc8dlLK5KJaU53bVG3emmQZnNXzKU9+k+NDG6u7LiBxG/k8TGD5 l5Y240HUQyvybdWVtf1P7O/KvfDhEBUuGFSxJw+VM8aBfFVTiQet6UFb3FuZCKQsT9SI QEfNHSRWk890iI5ZwW2JOFwrjII0eBte28fRMI0VuINsgq1PGrNqMjPsnv9d67FHY594 l7/g== X-Gm-Message-State: AOAM530yPNrrQPkKFIj3nLIj6OI2qjXi1fRxvteUy8v/G80+swekLukX cCPNhTiGGrmzb1JV2OhBhWmSRWwF5nG9U6xO6J7oDZH87nLWSuXYRc9ddmhx6GbcVgZMQ0iKQ42 wdiYvcqE= X-Received: by 2002:a37:5cc6:: with SMTP id q189mr28357084qkb.305.1625694818309; Wed, 07 Jul 2021 14:53:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwsZ1peTqyLTDFQWmeW561dR3L+9FV57oBD61s1J5y7qkir3hnDfIeyulz5rWcUAB2Q+SzwQg== X-Received: by 2002:a37:5cc6:: with SMTP id q189mr28357071qkb.305.1625694818124; Wed, 07 Jul 2021 14:53:38 -0700 (PDT) Received: from redhat.com ([2601:184:4780:4310::8e66]) by smtp.gmail.com with ESMTPSA id h6sm144473qtb.95.2021.07.07.14.53.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jul 2021 14:53:37 -0700 (PDT) Date: Wed, 7 Jul 2021 17:53:35 -0400 From: Marek Polacek To: Martin Sebor Cc: Jonathan Wakely , gcc mailing list Subject: Re: where is PRnnnn required again? Message-ID: References: <9121724e-e741-9bad-a39d-d6ac49422589@gmail.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 21:53:42 -0000 On Wed, Jul 07, 2021 at 03:35:35PM -0600, Martin Sebor wrote: > On 7/7/21 2:42 PM, Jonathan Wakely wrote: > > > > > > On Wed, 7 Jul 2021, 17:39 Martin Sebor, > > wrote: > > > > On 7/6/21 4:09 PM, Jonathan Wakely wrote: > > > > > > > > > On Tue, 6 Jul 2021, 22:45 Martin Sebor via Gcc, > > > > >> wrote: > > > > > >     On 7/6/21 3:36 PM, Marek Polacek wrote: > > >      > On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via > > Gcc wrote: > > >      >> I came away from the recent discussion of ChangeLogs > > requirements > > >      >> with the impression that the PRnnnn bit should be in the > > subject > > >      >> (first) line and also above the ChangeLog part but > > doesn't need > > >      >> to be repeated again in the ChangeLog entries.  But my commit > > >      >> below was rejected last Friday with the subsequent > > error.  Adding > > >      >> PR middle-end/98871 to the ChangeLog entry let me push > > the change: > > >      >> > > >      >> > > https://gcc.gnu.org/g:6feb628a706e86eb3f303aff388c74bdb29e7381 > > >      >> > > >      >> I just had the same error happen now, again with what > > seems like > > >      >> a valid commit message.  Did I misunderstand something or has > > >      >> something changed recently? > > >      >> > > >      >> Martin > > >      >> > > >      >> commit 8a6d08bb49c2b9585c2a2adbb3121f6d9347b780 (HEAD -> > > master) > > >      >> Author: Martin Sebor > > >> > > >      >> Date:   Fri Jul 2 16:16:31 2021 -0600 > > >      >> > > >      >>      Improve warning suppression for inlined functions > > [PR98512]. > > >      >> > > >      >>      Resolves: > > >      >>      PR middle-end/98871 - Cannot silence > > -Wmaybe-uninitialized at > > >      >> declaration si > > >      >> te > > >      >>      PR middle-end/98512 - #pragma GCC diagnostic ignored > > >     ineffective in > > >      >> conjunct > > >      >> ion with alias attribute > > >      > > > >      > This should be just > > >      > > > >      >       PR middle-end/98871 > > >      >       PR middle-end/98512 > > >      > > > >      > , no? > > > > > >     Does it matter if there's text after the PR ...? > > > > > > > > > > > > Yes. With extra text the whole line is just treated as arbitrary > > text, > > > not a "PR component/nnnn" string. So with the extra text it won't be > > > added to the ChangeLog file, and won't match the PR in the > > subject line. > > > > > >        I managed to push > > > > > > https://gcc.gnu.org/pipermail/gcc-cvs/2021-July/350316.html > > > > > >     that uses the same style earlier today > > > > > > > > > But will it add the PR numbers to the ChangeLog? I think the > > answer is > > > no (in which case you could edit the ChangeLog tomorrow if you > > want them > > > to be in there). > > > > It updated Bugzilla but it didn't add the PR numbers to the ChangeLog > > entries.  I still don't (obviously) understand the rules the hook uses > > for what to update or the rationale for them.  It seems as though > > the PR in the subject is used to update only Bugzilla but not also > > update the ChangeLogs (why not?) > > > > > > Because they are two completely separate processes. Verifying the commit > > message format is done by a git hook, and you can run exactly the same > > checks locally before pushing a commit. > > > > Updating bugzilla is done by a separate and different process, which has > > been in place for years (decades?) before we switched to git. > > I don't mean to turn this into a contentious back and forth but > "because this is how it works" or "because this is how it's been > done for eons" aren't a rationale, at least not a satisfying one. > > Do you not agree that it would be better to be able to mention > the PR or PRs just once and have all our scripts work with it? > If you do then is something keeping us from making those changes? > > Martin > > PS To be clear, I'm suggesting that all these work the same and > update Bugzilla as well as ChangeLogs, both with and without > a space after PR and both with and without a component name after > the PR. > > 1) PR only in title. > Fix foobar [PR12345] > > gcc/ChangeLog: > * foo.c (bar): Fix it. The script would have to derive the component name from the PR number. That might a complication. > 2) PR (with or without additional text after it) after title and > before ChageLogs. > Fix foobar. > > PR12345 - foobar broken > > gcc/ChangeLog: > * foo.c (bar): Fix it. Looks like the best variant to me (I agree that enabling "- " after the PR number would be good). > 3) PR only in ChangeLogs. > Fix foobar. > > gcc/ChangeLog: > PR 12345 > * foo.c (bar): Fix it. I would be really unhappy with this one because I often look for PR numbers in the GCC mailing list archives and so having those numbers in email subjects helps tremendously. Therefore, best if people continue putting the #s in the subject. I'm not sure why you keep hitting so many issues; git addlog takes care of this stuff for me and I've had no trouble pushing my patches. Is there a reason you don't use it also? Marek