From: Shuah Khan <skhan@linuxfoundation.org>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs?
Date: Fri, 28 Jun 2019 15:07:01 -0600 [thread overview]
Message-ID: <5a778d63-24c3-cf15-2444-49e67f4e1b96@linuxfoundation.org> (raw)
In-Reply-To: <20190628205102.GA3131@agluck-desk2.amr.corp.intel.com>
On 6/28/19 2:51 PM, Luck, Tony wrote:
> On Fri, Jun 28, 2019 at 02:11:28PM -0600, Shuah Khan wrote:
>> In a recent patch discussion, I learned that some maintainers would like
>> to see patch version changes in the commit log.
>>
>> I went looking in the git log and found a handful of recent commits with
>> "Changes since" type information in the commit logs. It appears to be
>> maintainer preference and a recent trend.
>>
>> I see the value in including the information. It can be informative
>> and valuable for future work in the area.
>>
>> Is this something that we would like to see in all commits going forward? If
>> so, updating submitting patch documentation and making
>> sure the version information evolves from "informal" to more formal
>> nature that fits in with the commit logs would be helpful.
>>
>> Making sure it doesn't get out of hand and commit logs don't
>> become too long to be useful would also be helpful.
>>
>> Late entry, as I happened to come across this a day or two ago.
>
> Sounds somewhat pointless. Picking on a recent commit I see:
>
> Changes since:
> v2:
> - Added Fixes tag to patch 1
> - Fixed typo
> - added GSWIP_TABLE_MAC_BRIDGE_STATIC and made use of it
> - used GSWIP_TABLE_MAC_BRIDGE in more places
>
> v1:
> - fix typo signle -> single
>
> I don't see why someone in the future trying to debug some problem
> introduced by this commit would care that earlier versions had some
> spelling mistakes or were missing a Fixes: tag. :-)
>
Right. One of reasons I started this thread is to avoid this type of
change info. getting in which isn't really useful.
> Where substantial changes were made between patch versions it
> would be useful if the commit logs were adapted to say things like:
>
> "We considered using technique X to do this but rejected
> it because person Y said it had problem Z"
>
There is value to having information about alternatives if any.
But not the trivial change history.
> That captures for posterity the useful information without
> bulking up the commit log with the blow-by-blow deltas of
> how the patch series evolved across 27 versions submitted
> to the mailing list.
>
Yes this is really my concern that once we start accepting patches
with patch version information without paying attention to the
quality and setting some guidelines, we can end up with very long
commit logs.
thanks,
-- Shuah
next prev parent reply other threads:[~2019-06-28 21:07 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-28 20:11 [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? Shuah Khan
2019-06-28 20:51 ` Luck, Tony
2019-06-28 21:05 ` Kees Cook
2019-06-28 21:07 ` Shuah Khan [this message]
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
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 publicly 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=5a778d63-24c3-cf15-2444-49e67f4e1b96@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=tony.luck@intel.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).