From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 0990E3835806 for ; Wed, 7 Jul 2021 22:18:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0990E3835806 Received: by mail-oi1-x229.google.com with SMTP id r29so5244975oiw.13 for ; Wed, 07 Jul 2021 15:18:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/eZcW2SM2eACxyAdV4v19z+lviDZllb1ujidYWPrheY=; b=UfuGaWF5/MCtwvaXXbMvwb8ou4EsS6uYty4ok2G2EuXnehbd0W0P8AF2wCE6yh7j9+ zHlWmuVSD6pQ2JH1BDXl4lSnm3lEDOquc85ScH9LkGhePcEVc/H3vkuO8AS/ltGn++1O IMeQcBsF8F02V29DhwuvTNY6U4pFibZeR4Al8MWH/TFtlvCLeZuWnrqbnMfqXmXmWVSW NghKH5n9GPhVh86gm01mPFxCv/y07gVyLXgDMUzVeFQ1jPQ5RhGvfFJKJkHWYbz/iR/q 6RNdBY1itSfVaPGzCHf4+aSC6SmcQNE0NPsIzTQm7KjLL2KR53MczVeN0HicvAigZ3AP 2x6A== X-Gm-Message-State: AOAM5321/nR/n6JYDKIAVn1XSShi2D2oKBCq/UV4TXsuNn5EytpxGPC5 8cA+bVHzpWYIN9+ZkJuGR9q6oyG+sls= X-Google-Smtp-Source: ABdhPJwdJ33RSEnOINt51ZF2Es5+onCGrWwyfli+9/18nyr4HOWojrcW9OR1orZFAOxQLahSpsTmXA== X-Received: by 2002:aca:4483:: with SMTP id r125mr1098835oia.78.1625696305305; Wed, 07 Jul 2021 15:18:25 -0700 (PDT) Received: from [192.168.0.41] (75-166-102-22.hlrn.qwest.net. [75.166.102.22]) by smtp.gmail.com with ESMTPSA id z63sm37830ooa.17.2021.07.07.15.18.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 15:18:25 -0700 (PDT) Subject: Re: where is PRnnnn required again? To: Marek Polacek Cc: Jonathan Wakely , gcc mailing list References: <9121724e-e741-9bad-a39d-d6ac49422589@gmail.com> From: Martin Sebor Message-ID: <734e36bd-5adb-feed-7e89-d63d233198a4@gmail.com> Date: Wed, 7 Jul 2021 16:18:24 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 22:18:28 -0000 On 7/7/21 3:53 PM, Marek Polacek wrote: > 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. Right, it would have to get from Bugzilla. The mklog.py script has an option to do that (get both the PR title and component). > >> 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? I probably have a completely different workflow. Git addlog isn't a git command (is it some sort of a GCC extension?), and what I put in the subject of my emails is almost never the same thing as what I put in the commit message. I'm not suggesting people change their habits, just that our tooling not unnecessarily penalize those of us who dot things a little differently. Martin