From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 363801CB4 for ; Tue, 2 Jul 2019 15:30:10 +0000 (UTC) Received: from Galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 77AB6836 for ; Tue, 2 Jul 2019 15:30:09 +0000 (UTC) Date: Tue, 2 Jul 2019 17:30:06 +0200 (CEST) From: Thomas Gleixner To: James Bottomley In-Reply-To: <1562080257.3321.19.camel@HansenPartnership.com> Message-ID: References: <7b73e1b7-cc34-982d-2a9c-acf62b88da16@linuxfoundation.org> <20263.1561993564@warthog.procyon.org.uk> <1561996215.3551.49.camel@HansenPartnership.com> <1562077203.3321.2.camel@HansenPartnership.com> <1562080257.3321.19.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2 Jul 2019, James Bottomley wrote: > On Tue, 2019-07-02 at 16:49 +0200, Thomas Gleixner wrote: > > On Tue, 2 Jul 2019, James Bottomley wrote: > > > On Mon, 2019-07-01 at 19:54 +0200, Thomas Gleixner wrote: > > > > The link to V2 is in both cases in the cover letter. That's > > > > sufficient. Yes, it might not be necessary, but I just recently > > > > ended up wasting an hour finding an earlier version because the > > > > cover letter subject changed slightly. I surely have better > > > > things to do. > > > > > > I'm not arguing against changelogs in the patches themselves as > > > long as they're below the commit message --- cutoff. In fact I > > > think that's best practice for reviewers. I'm just arguing making > > > a link tag mandatory would impose an enforcement burden on a lot of > > > subsystems which would provide no benefit to them), so I don't mind > > > it's being optional but it shouldn't be mandatory. > > > > What's the burden exactly? > > Not everyone knows what a message ID is or how to find it, so we'd have > to explain why the patch was rejected (or simply have the maintainer > add it at commit time, which currently involves some effort). Quite a > few of the list archives mangle it so someone would have to notice this > or unmangle it. > > > You mean that people would have to add them manually? > > Most email tools don't show you the msgid, so if you're simply doing > driveby commits now we have to explain to you how to find it ... > remember linux-scsi isn't currently on lore so we can't just say "use > the lore archive". The submitter has not to do anything for a drive by patch. The maintainer who grabs it from the list adds the tags (with tools). > There's also a knock on: for this to be useful, the commit series needs > to be threaded. I've actually no objection to making this one > mandatory I'm just noting it's another precursor we need to think > about. > > > People who use the link tag today have their homebrewn scripts to add > > them automatically and it shouldn't be rocket science to add that to > > git, patchwork whatever. > > So if we find a way of automating this globally, I'm completely happy. > However, I would also note that whatever script does this could likely > also be run by you after the fact to generate the back link, so > foolproof automation also lessens the need to make this a mandatory > commit tag. That's what I'm doing today. My mbox to quilt converter inserts the Link tag. So let's take a step back. 1) Link tag in the commit itself. That's added by the person who applies a patch from mail, i.e. maintainer. That needs tooling support in git, patchwork etc. which should be a solvable problem. 2) Link to a previous version of patch series in the cover letter Lot of people provide already links in their cover letter. Many of them unfortunately use lkml.org which is a pain, but it's better than nothing. Ideally we can bring people to use the MSG id based links because they do not depend on any particular archive. That needs a bit more education. Proper documentation should solve that over time. If people use lkml.org for the link until they figure out what a message id is, fine. Thanks, tglx