Ksummit-Discuss Archive on lore.kernel.org
 help / color / Atom feed
From: Jan Kara <jack@suse.cz>
To: Theodore Ts'o <tytso@mit.edu>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs?
Date: Wed, 3 Jul 2019 16:10:13 +0200
Message-ID: <20190703141013.GB16008@quack2.suse.cz> (raw)
In-Reply-To: <20190703135012.GC2041@mit.edu>

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

  reply index

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28 20:11 Shuah Khan
2019-06-28 20:51 ` Luck, Tony
2019-06-28 21:05   ` Kees Cook
2019-06-28 21:07   ` Shuah Khan
2019-06-28 21:13     ` James Bottomley
2019-06-28 21:42       ` Shuah Khan
2019-06-28 21:07   ` Wolfram Sang
2019-06-29  6:19   ` Thomas Gleixner
2019-06-29  9:10     ` Christian Brauner
2019-06-29 13:43     ` Andrea Parri
2019-06-29 15:16       ` Thomas Gleixner
2019-06-30 16:31         ` Konstantin Ryabitsev
2019-07-01  7:20           ` Peter Zijlstra
2019-07-01  7:49             ` Thomas Gleixner
2019-07-01  7:53               ` Takashi Iwai
2019-07-17  9:23                 ` Dan Carpenter
2019-07-17  9:27                   ` Dan Carpenter
2019-07-17  9:28                   ` Greg KH
2019-07-17 16:09                     ` Linus Walleij
2019-07-17 20:44                       ` Greg KH
2019-07-18  9:09                       ` Linus Walleij
2019-07-22 17:02                       ` Kees Cook
2019-07-22 17:12                         ` Joe Perches
2019-07-01 17:27               ` Steven Rostedt
2019-07-01 17:55                 ` Thomas Gleixner
2019-07-01  9:48           ` Andrea Parri
2019-07-01  9:51             ` Andrea Parri
2019-07-02  4:40     ` Leon Romanovsky
2019-07-02  7:27       ` Geert Uytterhoeven
2019-07-02  9:48         ` Leon Romanovsky
2019-06-29  6:57   ` Takashi Iwai
2019-06-29  7:09     ` Thomas Gleixner
2019-06-29  7:18       ` Takashi Iwai
2019-06-29 11:20         ` Mark Brown
2019-06-30 16:01           ` Mauro Carvalho Chehab
2019-07-01  1:35             ` Andrew Donnellan
2019-07-01 11:10               ` Mark Brown
2019-08-08  5:24               ` Andrew Donnellan
2019-07-01  9:05       ` Jiri Kosina
2019-07-01  9:15         ` Sergey Senozhatsky
2019-07-04 12:15       ` Michael Ellerman
2019-07-04 13:24         ` Geert Uytterhoeven
2019-07-04 14:16           ` Thomas Gleixner
2019-07-05  3:37             ` Michael Ellerman
2019-07-05  4:10               ` Michael Ellerman
2019-07-05  6:28                 ` Thomas Gleixner
2019-07-05  8:24                   ` Geert Uytterhoeven
2019-07-04 14:22         ` James Bottomley
2019-07-05  3:24           ` Michael Ellerman
2019-07-06 14:02             ` Alexandre Belloni
2019-07-06 14:57               ` James Bottomley
2019-07-05  3:40           ` Michael Ellerman
2019-07-05  8:40           ` Geert Uytterhoeven
2019-06-28 21:07 ` James Bottomley
2019-07-01 15:06 ` David Howells
2019-07-01 15:40   ` Thomas Gleixner
2019-07-01 15:48     ` Laurent Pinchart
2019-07-01 15:50     ` James Bottomley
2019-07-01 17:54       ` Thomas Gleixner
2019-07-02 14:20         ` James Bottomley
2019-07-02 14:49           ` Thomas Gleixner
2019-07-02 15:10             ` James Bottomley
2019-07-02 15:18               ` James Bottomley
2019-07-02 15:39                 ` Shuah Khan
2019-07-02 15:51                   ` James Bottomley
2019-07-02 16:30                     ` Kees Cook
2019-07-02 21:16                       ` Konstantin Ryabitsev
2019-07-02 21:33                       ` James Bottomley
2019-07-02 22:07                         ` Thomas Gleixner
2019-07-02 22:26                           ` James Bottomley
2019-07-02 22:43                             ` Theodore Ts'o
2019-07-02 22:49                               ` Thomas Gleixner
2019-07-03 23:52                                 ` Ralf Ramsauer
2019-07-02 22:53                               ` James Bottomley
2019-07-02 23:12                                 ` Thomas Gleixner
2019-07-02 23:04                               ` Kees Cook
2019-07-02 23:18                                 ` Theodore Ts'o
2019-07-02 23:31                                   ` Kees Cook
2019-07-02 23:33                                   ` James Bottomley
2019-07-03  4:16                                     ` Theodore Ts'o
2019-07-03  4:50                                       ` James Bottomley
2019-07-03 14:42                                         ` Kees Cook
2019-07-02 23:41                                   ` Kees Cook
2019-07-03  7:51                                     ` Greg KH
2019-07-03  8:56                               ` Laurent Pinchart
2019-07-03  9:12                                 ` Thomas Gleixner
2019-07-03 12:39                                   ` Leon Romanovsky
2019-07-03 22:53                                     ` Laurent Pinchart
2019-07-03 13:50                                 ` Theodore Ts'o
2019-07-03 14:10                                   ` Jan Kara [this message]
2019-07-03 17:05                                     ` Mark Brown
2019-07-03 19:11                                   ` Frank Rowand
2019-07-05  9:26                                   ` Linus Walleij
2019-07-05 19:34                                     ` Mike Rapoport
2019-07-06  4:42                                     ` Theodore Ts'o
2019-07-07 21:56                                       ` Frank Rowand
2019-07-03 23:03                                 ` James Bottomley
2019-07-04  7:10                                   ` Geert Uytterhoeven
2019-07-05  9:03                                 ` Linus Walleij
2019-07-02 22:48                             ` Thomas Gleixner
2019-07-02 23:05                               ` James Bottomley
2019-07-02 19:03                     ` Shuah Khan
2019-07-02 15:30               ` Thomas Gleixner
2019-07-02 15:40                 ` James Bottomley
2019-07-02 15:49                   ` Thomas Gleixner
2019-07-02 20:44               ` Jiri Kosina

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190703141013.GB16008@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Ksummit-Discuss Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/ksummit-discuss/0 ksummit-discuss/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ksummit-discuss ksummit-discuss/ https://lore.kernel.org/ksummit-discuss \
		ksummit-discuss@lists.linuxfoundation.org
	public-inbox-index ksummit-discuss

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.linuxfoundation.lists.ksummit-discuss


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git