Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs?

[Thomas Gleixner <tglx@linutronix.de>]

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