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

[Jan Kara <jack@suse.cz>]

On Wed 03-07-19 09:50:12, Theodore Ts'o wrote:
> 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.

So I agree in a lot of cases Link tag is going to be useless. OTOH I'm
willing to put up with the useless Link tag for the cases where it does
help - e.g. multiple times I'm been chasing mailing lists to find out
what's the latest posted version of some patch and what other patches are
in the series so that I could backport them as well. And the Link tag would
help with this or even make it possible to automate this to some extent...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR