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

["Theodore Ts'o" <tytso@mit.edu>]

On Wed, Jul 03, 2019 at 11:56:20AM +0300, Laurent Pinchart wrote:
> 
> I may have missed the obvious, but while this should work great for
> patches applied with git-am, what's the expected workflow for patches
> written by the author of a pull request ? I certainly post my own
> patches for review on mailing lists, but I don't fetch them back from
> the list before sending a pull request. Do we want to move towards a
> model where maintainers should retrieve their own patches from the lists
> (or from patchwork) ?

So here's my (Unpopular Puffin?) opinion --- I don't think all patches
need to have a Link header.  Many don't today, and it's no great
tragedy.  If you are updating spelling mistakes in kernel
documentation, or you are fixing compiler, sparse, or Coverity
warnings, there's generally going to be nothing terribly interesting
on the e-mail thread anyway.  So why go to extra effort to create the
link?

The patches where the Link tag will be most interesting are the ones
that are adding a new feature, or have something that has sparked a
lot of controversy.  However, today, merely finding the last V22
version of the patch series doesn't necessarily help you find the V21,
or V20, or V19, etc., patches.  Most people do *not* send out the V21
version a 50 patch series as a reply to the V20 --- and that's
actually a good thing, because it makes the reply chain in a mutt
reader like mutt be completely unmangeable.

And even if they do, how often will it be useful to go through that
kind of detailed legislative history, even presuming that it exists?
So 99% of the time, the tag is going to have very highly limited
value, just as including in the commit description:

v3
  - Fixed whitespace nits

v2
 - Used an explicit slab cache instead of kmalloc()
 - Fixed spelling nit in documentation

is ***really*** not interesting or appropriate.  And putting in a Link
tag so people can read all of those review comments in all their glory
is really not going to be all that interesting either.

Personally, if there is a case where it will be useful, it would
actually be better for developers to summarize the comments, and
design alternatives, considered and rejected, etc., in a cover letter,
or better yet in the kernel documentation as part of the design doc
for a largish feature, and then if it is a cover letter e-mailed out
to the mailing list, include a link to the URL of the cover letter
with some text so that a human being reading the commit log will know
that there is something actually worth their time to read, as opposed
to being treated to a huge amount of legislative history that, at the
end of the day, be a complete waste of time to someone trying to debug
a live production problem causing data outages for their company.

The reality though is this is a lot of extra work we're asking of the
developer, so this automated fashion is a technological solution to
something which is really a social problem --- and hopefully there
will be a few cases where it will actually result in a net benefit.

Regards,

					- Ted