From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 9BC823AAB4BD for ; Fri, 11 Jun 2021 17:02:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9BC823AAB4BD Received: by mail-ot1-x330.google.com with SMTP id i12-20020a05683033ecb02903346fa0f74dso3768015otu.10 for ; Fri, 11 Jun 2021 10:02:54 -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=5va6sqYp84UV0DcY1VkL08hEd6Z7Dv8fXsgyq1CD4m8=; b=K1l1nF0foE3U7+Hk8sGxO1ijA1lyWNFEBcObiQ6q/eHH6BO1UwuyJXFrjcjpPrOLYB oqycHIiVHsIf6NJ9qR6ejFjiYGn7OI6+upZEmp6sx4zbgMadDzeCIUHN53HuCW93wXI5 oPvDgiJuQms7GnqzQcQIDKFK/C4mKGAMQpxs1nrLabAIEfDJ4gLQl6Hd4pV+76bE2WK5 iDkneKVYX4JL93iYCvrUmzhTaPxwYzTqCt3zkIb5y0zRsqr66rBM7cNqyckJa/eDl4sa 07Z7kQnGp3dICuMs1OAtkGaK3em4J5/UJo1/MxMhzj3B6jf3pqZNJ2bVoN1dHsYgnUUq CBvA== X-Gm-Message-State: AOAM5328s15QruQ+l60Ah5lhDS7z7CMHKPHbr40gmmg51DqjZxUCSXhW BB9PpGHYNMiJgG4f0lQrFZzHXYEzDvY= X-Google-Smtp-Source: ABdhPJwK2At1Ch8r00/wM8sR3xUJbcQkGxzLUVzPj9RXnJkRgKc1gZTJTs4aYUeWphFxdXaf+kxtgA== X-Received: by 2002:a05:6830:1b6e:: with SMTP id d14mr3972200ote.186.1623430973762; Fri, 11 Jun 2021 10:02:53 -0700 (PDT) Received: from [192.168.0.41] (97-118-122-241.hlrn.qwest.net. [97.118.122.241]) by smtp.gmail.com with ESMTPSA id z4sm1428703otq.48.2021.06.11.10.02.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Jun 2021 10:02:53 -0700 (PDT) Subject: Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog To: Jonathan Wakely Cc: Jakub Jelinek , gcc@gcc.gnu.org References: <20210610100851.GD7746@tucnak> <1230cb99-ed83-3e4e-8362-94f03ee021bc@gmail.com> <3228435b-aba0-6157-3266-c0f025822829@gmail.com> <5f89ddc0-aed4-2c20-0979-dfafb29046ee@gmail.com> <20210610173005.GI7746@tucnak> <20210610190941.GJ7746@tucnak> From: Martin Sebor Message-ID: <58b63929-01f5-038c-931c-9ff8349d9f95@gmail.com> Date: Fri, 11 Jun 2021 11:02:52 -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: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Fri, 11 Jun 2021 17:02:56 -0000 On 6/11/21 3:13 AM, Jonathan Wakely wrote: > On Thu, 10 Jun 2021 at 22:16, Martin Sebor wrote: >> I don't see why the script users should be subjected to this tedium >> when it can be done in the script itself with (presumably) only >> a little more effort. The proposed change is, IMO, a step in >> the wrong direction. > > I don't see why "improve the mklog.py script to automatically follow > the policy" is in conflict with "enforce the policy". > > If the script can be improved to do the right thing automatically when > you commit (it's not clear if it can be improved that way, but let's > say it can) then what's the problem with enforcing it when you push > the commit to the server? What are you being "subjected to"? If it's > automated, what is "this tedium"? You've already followed the policy, > why do you care if there are checks to make sure that everybody > follows the policy, including the people not using the script and > writing the entire commit msg by hand? > > I'm not saying we are going to enforce every part of the policy > (because the policy isn't even clear right now), but if we wanted to > do it later, I don't understand your objection. My objection is to making our policies and tools more restrictive than they need to be. We shouldn't expect everyone to study whole manuals just to figure out how to successfully commit a change (or learn how to format it just the right way). It should be easy. Setting this discussion aside for a moment and using a different example, the commit hook rejects commit messages that don't start ChangeLog entries with tabs. It also rejects commit messages that don't list all the same test files as those changed by the commit (and probably some others as well). That's in my view unnecessary when the hook could just replace the leading spaces with tabs and automatically mention all the tests. I see this proposal as heading in the same direction. Rather than making the script fix things up if we get them wrong it would reject the commit, requiring the user to massage the ChangeLog by hand into an unnecessarily rigid format. Martin PS I think I referred to mklog.py when I meant gcc-commit-mklog, confusing the discussion and probably even myself. Sorry about that. The mklog.py script is great. It helps us avoid some of these mistakes. But the script isn't perfect and commit messages for some more involved changes still need to be hand-edited. That's when the mistakes usually creep back in. But the fact that we need a script to preformat a commit message for us in the stringent format that makes the commit hook happy seems like a pretty good indication that our policies and requirements are too onerous for most of us to get all the details right.