Ksummit-Discuss Archive on lore.kernel.org
 help / color / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
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 12:11:09 -0700
Message-ID: <454fdfd3-f45e-e307-c0cb-2dbc91c179e0@gmail.com> (raw)
In-Reply-To: <20190703135012.GC2041@mit.edu>

On 7/3/19 6:50 AM, 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,

It would be really nice to have such a summary.  I would encourage
developers to provide such, but not require it.  It is a lot of
work to create such a document.

On the other hand, given a choice between the summary and a link to
the discussion, I would prefer the link to the whole discussion
because the person writing the summary can not predict what detail
(that may appear insignificant at the time) is critical to the person
five years later who is researching the feature.

-Frank

> 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
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

  parent 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
2019-07-03 17:05                                     ` Mark Brown
2019-07-03 19:11                                   ` Frank Rowand [this message]
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=454fdfd3-f45e-e307-c0cb-2dbc91c179e0@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --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