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

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

[Shuah Khan]

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.

thanks,
-- Shuah

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

[Luck, Tony]

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. :-)

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"

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.

-Tony

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

[Kees Cook]

On Fri, Jun 28, 2019 at 01:51:03PM -0700, 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.
> 
> 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"
> 
> 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.

Yeah, I usually have maintainers want (and I want) to see rationales
and prior thinking/approaches mentioned in a changelog, but the little
details tend not to be very important.

-- 
Kees Cook

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

[Shuah Khan]

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

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

[James Bottomley]

On Fri, 2019-06-28 at 15:07 -0600, Shuah Khan wrote:
> On 6/28/19 2:51 PM, Luck, Tony wrote:
> > On Fri, Jun 28, 2019 at 02:11:28PM -0600, Shuah Khan wrote:
[...]
> > 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.

But we already have the cregit project that tries to attach mailing
list discussion pointers to every semantic tag in the source code

https://cregit.linuxsources.org/code/

It's only up to 4.20 but it's still useful.  I think the complexity of
our development process means that we need the changelog to be
succinct, so a brief discussion of the reasons for the patch, not every
point that was raised and considered during the mailing list discussion
because that's asking to have long winded and hard to read changelogs. 
If someone wants the full history they use a project like cregit to
find it.

James

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

[Shuah Khan]

On 6/28/19 3:13 PM, James Bottomley wrote:
> On Fri, 2019-06-28 at 15:07 -0600, Shuah Khan wrote:
>> On 6/28/19 2:51 PM, Luck, Tony wrote:
>>> On Fri, Jun 28, 2019 at 02:11:28PM -0600, Shuah Khan wrote:
> [...]
>>> 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.
> 
> But we already have the cregit project that tries to attach mailing
> list discussion pointers to every semantic tag in the source code
> 
> https://cregit.linuxsources.org/code/
> 

Right. I use cregit for my research into changes. It does pull in
discussions it can find.

> It's only up to 4.20 but it's still useful.  I think the complexity of
> our development process means that we need the changelog to be
> succinct, so a brief discussion of the reasons for the patch, not every
> point that was raised and considered during the mailing list discussion
> because that's asking to have long winded and hard to read changelogs.
> If someone wants the full history they use a project like cregit to
> find it.
> 
I am not advocating adding change history to commit logs. My preference
is leaving the patch history out of the commit log.

I have the same concerns about commit logs getting out of hand with
change history even if it could be useful to have in handful of cases.

I am seeing change history popping up in recent commits and we do have
some maintainers that like to see the change history in commit logs.

I want to make sure it is given some thought as opposed to becoming the
norm without proper discussion. This can lead to lots of confusion when
sending patches as to should this information be included or not.

thanks,
-- Shuah

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]


> 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. :-)
> 
> 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"
> 
> 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.

I fully agree.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Thomas Gleixner]

On Fri, 28 Jun 2019, 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.

> 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"
> 
> 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.

What's really useful is when the commit has a Link tag:

       https://lore.kernel.org/lkml/$MESSAGE-ID

and if the submitters provide the same kind of link in their V(N)
submission pointing to the V(N-1) in the cover letter:

       https://lore.kernel.org/lkml/$MESSAGE-ID-V(N-1)

If it's a single patch the link can be in the patch itself after the ---
separator. That allows a quick lookup of the history.

I also really want the change history to be at that place. i.e.

 Subject ....

 changelog text

 Tags...
 Signed-off-by: Joe Hacker

 ---

 V3: Fixed typo

 V2: Made it work
     https://lore.kernel.org/.... (if single patch)

 ---

 diffstat

 ---

 patch

That way tools just strip the changes section away and the maintainer does
not have to handle it manually.

Can we pretty please agree on that format and make it mandatory?

Thanks,

	tglx

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

[Christian Brauner]

On Sat, Jun 29, 2019 at 08:19:55AM +0200, Thomas Gleixner wrote:
> On Fri, 28 Jun 2019, 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.
> 
> > 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"
> > 
> > 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.
> 
> What's really useful is when the commit has a Link tag:
> 
>        https://lore.kernel.org/lkml/$MESSAGE-ID
> 
> and if the submitters provide the same kind of link in their V(N)
> submission pointing to the V(N-1) in the cover letter:
> 
>        https://lore.kernel.org/lkml/$MESSAGE-ID-V(N-1)
> 
> If it's a single patch the link can be in the patch itself after the ---
> separator. That allows a quick lookup of the history.
> 
> I also really want the change history to be at that place. i.e.
> 
>  Subject ....
> 
>  changelog text
> 
>  Tags...
>  Signed-off-by: Joe Hacker
> 
>  ---
> 
>  V3: Fixed typo
> 
>  V2: Made it work
>      https://lore.kernel.org/.... (if single patch)
> 
>  ---
> 
>  diffstat
> 
>  ---
> 
>  patch
> 
> That way tools just strip the changes section away and the maintainer does
> not have to handle it manually.
> 
> Can we pretty please agree on that format and make it mandatory?

That sounds really useful. Imho, the ideal is:
- patch submissions:
  - Thomas format outlined above
- commit message in Linus/Maintainers tree:
  - lore-Link to the last sent submission that turned into the accepted
    patch (again, Thomas)
  - but keeping specific version information v1, ..., vn out of the
    commit message

I do like lore-Links a lot and I have made quite heavy use of them in
commit messages by using the format:

"We did x because of y. For the full rationale see [1]."

and then add the end of the commit message right before the DCOs I have
a "References" section:

/* References */
[1]: [6]: https://lore.kernel.org/lkml/<ID>

If we could codify this somewhere in the kernel documentation I'm all for it!

Christian

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

[Andrea Parri]

> What's really useful is when the commit has a Link tag:
> 
>        https://lore.kernel.org/lkml/$MESSAGE-ID
> 
> and if the submitters provide the same kind of link in their V(N)
> submission pointing to the V(N-1) in the cover letter:
> 
>        https://lore.kernel.org/lkml/$MESSAGE-ID-V(N-1)
> 
> If it's a single patch the link can be in the patch itself after the ---
> separator. That allows a quick lookup of the history.
> 
> I also really want the change history to be at that place. i.e.
> 
>  Subject ....
> 
>  changelog text
> 
>  Tags...
>  Signed-off-by: Joe Hacker
> 
>  ---
> 
>  V3: Fixed typo
> 
>  V2: Made it work
>      https://lore.kernel.org/.... (if single patch)
> 
>  ---
> 
>  diffstat
> 
>  ---
> 
>  patch
> 
> That way tools just strip the changes section away and the maintainer does
> not have to handle it manually.
> 
> Can we pretty please agree on that format and make it mandatory?

Makes all sense to me.  One question/remark:

Documentation/process/submitting-patches.rst says:

 "If the patch follows from a mailing list discussion, give a URL to the
  mailing list archive; use the https://lkml.kernel.org/ redirector with
  a ``Message-Id``, to ensure that the links cannot become stale."

and it does not mention "lore.kernel.org": does this doc want an update?

FWIW, I've been trying to conform to "lkml.kernel.org"  (which currently
seems just a redirection to "lore.kernel.org")  since [1], and I do know
of at least a few subsystems out there recommending such URLs.

Thanks,
  Andrea

[1] https://lkml.kernel.org/r/20180412115022.GL4043@hirez.programming.kicks-ass.net

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

[Thomas Gleixner]

On Sat, 29 Jun 2019, Andrea Parri wrote:
> > Can we pretty please agree on that format and make it mandatory?
> 
> Makes all sense to me.  One question/remark:
> 
> Documentation/process/submitting-patches.rst says:
> 
>  "If the patch follows from a mailing list discussion, give a URL to the
>   mailing list archive; use the https://lkml.kernel.org/ redirector with
>   a ``Message-Id``, to ensure that the links cannot become stale."
> 
> and it does not mention "lore.kernel.org": does this doc want an update?

Yes. lkml.kernel.org/r was the initial redirector, but lore is the new
thing. 

> FWIW, I've been trying to conform to "lkml.kernel.org"  (which currently
> seems just a redirection to "lore.kernel.org")  since [1], and I do know

Yes, its switched from marc.info to lore.

> of at least a few subsystems out there recommending such URLs.

I find them pretty useful.

Thanks,

	tglx

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

[Konstantin Ryabitsev]

On Sat, Jun 29, 2019 at 05:16:18PM +0200, Thomas Gleixner wrote:
>> Makes all sense to me.  One question/remark:
>>
>> Documentation/process/submitting-patches.rst says:
>>
>>  "If the patch follows from a mailing list discussion, give a URL to the
>>   mailing list archive; use the https://lkml.kernel.org/ redirector with
>>   a ``Message-Id``, to ensure that the links cannot become stale."
>>
>> and it does not mention "lore.kernel.org": does this doc want an update?
>
>Yes. lkml.kernel.org/r was the initial redirector, but lore is the new
>thing.

FYI, lkml.kernel.org == lore.kernel.org in all respects. Using 
lore.kernel.org/r/<messageid> will match *any* mailing list archived at 
lore.kernel.org (for the full list, see https://lore.kernel.org/lists.html).
I prefer people use lore.kernel.org because that name doesn't imply that 
the search will only match LKML.

-K

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

[Peter Zijlstra]

On Sun, Jun 30, 2019 at 12:31:20PM -0400, Konstantin Ryabitsev wrote:
> On Sat, Jun 29, 2019 at 05:16:18PM +0200, Thomas Gleixner wrote:
> > > Makes all sense to me.  One question/remark:
> > > 
> > > Documentation/process/submitting-patches.rst says:
> > > 
> > >  "If the patch follows from a mailing list discussion, give a URL to the
> > >   mailing list archive; use the https://lkml.kernel.org/ redirector with
> > >   a ``Message-Id``, to ensure that the links cannot become stale."
> > > 
> > > and it does not mention "lore.kernel.org": does this doc want an update?
> > 
> > Yes. lkml.kernel.org/r was the initial redirector, but lore is the new
> > thing.
> 
> FYI, lkml.kernel.org == lore.kernel.org in all respects. Using
> lore.kernel.org/r/<messageid> will match *any* mailing list archived at
> lore.kernel.org (for the full list, see https://lore.kernel.org/lists.html).
> I prefer people use lore.kernel.org because that name doesn't imply that the
> search will only match LKML.

I much prefer https://lkml.kernel.org/r/$msgid over lore, because I can
change it to marc.info with a single character change. And while lore
has improved, the thing is still a horrible horrible ugly site (an
actual fixed frame for the thread overview, and hiding that 'Reply
instructions' and 'LKML Archive on lore.kernel.org' somewhow would
already be a big improvement).

Also, strlen("lkml.kernel.org/r/") < strlen("lore.kernel.org/lkml/").

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

[Thomas Gleixner]

On Mon, 1 Jul 2019, Peter Zijlstra wrote:

> On Sun, Jun 30, 2019 at 12:31:20PM -0400, Konstantin Ryabitsev wrote:
> > On Sat, Jun 29, 2019 at 05:16:18PM +0200, Thomas Gleixner wrote:
> > > > Makes all sense to me.  One question/remark:
> > > > 
> > > > Documentation/process/submitting-patches.rst says:
> > > > 
> > > >  "If the patch follows from a mailing list discussion, give a URL to the
> > > >   mailing list archive; use the https://lkml.kernel.org/ redirector with
> > > >   a ``Message-Id``, to ensure that the links cannot become stale."
> > > > 
> > > > and it does not mention "lore.kernel.org": does this doc want an update?
> > > 
> > > Yes. lkml.kernel.org/r was the initial redirector, but lore is the new
> > > thing.
> > 
> > FYI, lkml.kernel.org == lore.kernel.org in all respects. Using
> > lore.kernel.org/r/<messageid> will match *any* mailing list archived at
> > lore.kernel.org (for the full list, see https://lore.kernel.org/lists.html).
> > I prefer people use lore.kernel.org because that name doesn't imply that the
> > search will only match LKML.
> 
> I much prefer https://lkml.kernel.org/r/$msgid over lore, because I can
> change it to marc.info with a single character change. And while lore
> has improved, the thing is still a horrible horrible ugly site (an
> actual fixed frame for the thread overview, and hiding that 'Reply
> instructions' and 'LKML Archive on lore.kernel.org' somewhow would
> already be a big improvement).

But lore allows to reference all mailinglists which are archived
there, while lkml.k.org is hardcoded to lkml.

> Also, strlen("lkml.kernel.org/r/") < strlen("lore.kernel.org/lkml/").

Come on ....

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

[Takashi Iwai]

On Mon, 01 Jul 2019 09:49:56 +0200,
Thomas Gleixner wrote:
> 
> On Mon, 1 Jul 2019, Peter Zijlstra wrote:
> 
> > On Sun, Jun 30, 2019 at 12:31:20PM -0400, Konstantin Ryabitsev wrote:
> > > On Sat, Jun 29, 2019 at 05:16:18PM +0200, Thomas Gleixner wrote:
> > > > > Makes all sense to me.  One question/remark:
> > > > > 
> > > > > Documentation/process/submitting-patches.rst says:
> > > > > 
> > > > >  "If the patch follows from a mailing list discussion, give a URL to the
> > > > >   mailing list archive; use the https://lkml.kernel.org/ redirector with
> > > > >   a ``Message-Id``, to ensure that the links cannot become stale."
> > > > > 
> > > > > and it does not mention "lore.kernel.org": does this doc want an update?
> > > > 
> > > > Yes. lkml.kernel.org/r was the initial redirector, but lore is the new
> > > > thing.
> > > 
> > > FYI, lkml.kernel.org == lore.kernel.org in all respects. Using
> > > lore.kernel.org/r/<messageid> will match *any* mailing list archived at
> > > lore.kernel.org (for the full list, see https://lore.kernel.org/lists.html).
> > > I prefer people use lore.kernel.org because that name doesn't imply that the
> > > search will only match LKML.
> > 
> > I much prefer https://lkml.kernel.org/r/$msgid over lore, because I can
> > change it to marc.info with a single character change. And while lore
> > has improved, the thing is still a horrible horrible ugly site (an
> > actual fixed frame for the thread overview, and hiding that 'Reply
> > instructions' and 'LKML Archive on lore.kernel.org' somewhow would
> > already be a big improvement).
> 
> But lore allows to reference all mailinglists which are archived
> there, while lkml.k.org is hardcoded to lkml.
> 
> > Also, strlen("lkml.kernel.org/r/") < strlen("lore.kernel.org/lkml/").
> 
> Come on ....

If the size matters, how about just putting the message id?
Something like:
  Link: <alpine.DEB.2.21.1907010948310.1802@nanos.tec.linutronix.de>


Takashi

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

[Dan Carpenter]

On Mon, Jul 01, 2019 at 09:53:54AM +0200, Takashi Iwai wrote:
> On Mon, 01 Jul 2019 09:49:56 +0200,
> Thomas Gleixner wrote:
> > 
> > On Mon, 1 Jul 2019, Peter Zijlstra wrote:
> > 
> > > On Sun, Jun 30, 2019 at 12:31:20PM -0400, Konstantin Ryabitsev wrote:
> > > > On Sat, Jun 29, 2019 at 05:16:18PM +0200, Thomas Gleixner wrote:
> > > > > > Makes all sense to me.  One question/remark:
> > > > > > 
> > > > > > Documentation/process/submitting-patches.rst says:
> > > > > > 
> > > > > >  "If the patch follows from a mailing list discussion, give a URL to the
> > > > > >   mailing list archive; use the https://lkml.kernel.org/ redirector with
> > > > > >   a ``Message-Id``, to ensure that the links cannot become stale."
> > > > > > 
> > > > > > and it does not mention "lore.kernel.org": does this doc want an update?
> > > > > 
> > > > > Yes. lkml.kernel.org/r was the initial redirector, but lore is the new
> > > > > thing.
> > > > 
> > > > FYI, lkml.kernel.org == lore.kernel.org in all respects. Using
> > > > lore.kernel.org/r/<messageid> will match *any* mailing list archived at
> > > > lore.kernel.org (for the full list, see https://lore.kernel.org/lists.html).
> > > > I prefer people use lore.kernel.org because that name doesn't imply that the
> > > > search will only match LKML.
> > > 
> > > I much prefer https://lkml.kernel.org/r/$msgid over lore, because I can
> > > change it to marc.info with a single character change. And while lore
> > > has improved, the thing is still a horrible horrible ugly site (an
> > > actual fixed frame for the thread overview, and hiding that 'Reply
> > > instructions' and 'LKML Archive on lore.kernel.org' somewhow would
> > > already be a big improvement).
> > 
> > But lore allows to reference all mailinglists which are archived
> > there, while lkml.k.org is hardcoded to lkml.
> > 
> > > Also, strlen("lkml.kernel.org/r/") < strlen("lore.kernel.org/lkml/").
> > 
> > Come on ....
> 
> If the size matters, how about just putting the message id?
> Something like:
>   Link: <alpine.DEB.2.21.1907010948310.1802@nanos.tec.linutronix.de>

We could add an option to `git am` to save the Message-ID automatically.

regards,
dan carpenter

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

[Dan Carpenter]

On Wed, Jul 17, 2019 at 12:23:13PM +0300, Dan Carpenter wrote:
> On Mon, Jul 01, 2019 at 09:53:54AM +0200, Takashi Iwai wrote:
> > On Mon, 01 Jul 2019 09:49:56 +0200,
> > Thomas Gleixner wrote:
> > > 
> > > On Mon, 1 Jul 2019, Peter Zijlstra wrote:
> > > 
> > > > On Sun, Jun 30, 2019 at 12:31:20PM -0400, Konstantin Ryabitsev wrote:
> > > > > On Sat, Jun 29, 2019 at 05:16:18PM +0200, Thomas Gleixner wrote:
> > > > > > > Makes all sense to me.  One question/remark:
> > > > > > > 
> > > > > > > Documentation/process/submitting-patches.rst says:
> > > > > > > 
> > > > > > >  "If the patch follows from a mailing list discussion, give a URL to the
> > > > > > >   mailing list archive; use the https://lkml.kernel.org/ redirector with
> > > > > > >   a ``Message-Id``, to ensure that the links cannot become stale."
> > > > > > > 
> > > > > > > and it does not mention "lore.kernel.org": does this doc want an update?
> > > > > > 
> > > > > > Yes. lkml.kernel.org/r was the initial redirector, but lore is the new
> > > > > > thing.
> > > > > 
> > > > > FYI, lkml.kernel.org == lore.kernel.org in all respects. Using
> > > > > lore.kernel.org/r/<messageid> will match *any* mailing list archived at
> > > > > lore.kernel.org (for the full list, see https://lore.kernel.org/lists.html).
> > > > > I prefer people use lore.kernel.org because that name doesn't imply that the
> > > > > search will only match LKML.
> > > > 
> > > > I much prefer https://lkml.kernel.org/r/$msgid over lore, because I can
> > > > change it to marc.info with a single character change. And while lore
> > > > has improved, the thing is still a horrible horrible ugly site (an
> > > > actual fixed frame for the thread overview, and hiding that 'Reply
> > > > instructions' and 'LKML Archive on lore.kernel.org' somewhow would
> > > > already be a big improvement).
> > > 
> > > But lore allows to reference all mailinglists which are archived
> > > there, while lkml.k.org is hardcoded to lkml.
> > > 
> > > > Also, strlen("lkml.kernel.org/r/") < strlen("lore.kernel.org/lkml/").
> > > 
> > > Come on ....
> > 
> > If the size matters, how about just putting the message id?
> > Something like:
> >   Link: <alpine.DEB.2.21.1907010948310.1802@nanos.tec.linutronix.de>
> 
> We could add an option to `git am` to save the Message-ID automatically.

Oh, there already is a --message-id option...  Duh.

regards,
dan carpenter

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

[Greg KH]

On Wed, Jul 17, 2019 at 12:23:13PM +0300, Dan Carpenter wrote:
> On Mon, Jul 01, 2019 at 09:53:54AM +0200, Takashi Iwai wrote:
> > On Mon, 01 Jul 2019 09:49:56 +0200,
> > Thomas Gleixner wrote:
> > > 
> > > On Mon, 1 Jul 2019, Peter Zijlstra wrote:
> > > 
> > > > On Sun, Jun 30, 2019 at 12:31:20PM -0400, Konstantin Ryabitsev wrote:
> > > > > On Sat, Jun 29, 2019 at 05:16:18PM +0200, Thomas Gleixner wrote:
> > > > > > > Makes all sense to me.  One question/remark:
> > > > > > > 
> > > > > > > Documentation/process/submitting-patches.rst says:
> > > > > > > 
> > > > > > >  "If the patch follows from a mailing list discussion, give a URL to the
> > > > > > >   mailing list archive; use the https://lkml.kernel.org/ redirector with
> > > > > > >   a ``Message-Id``, to ensure that the links cannot become stale."
> > > > > > > 
> > > > > > > and it does not mention "lore.kernel.org": does this doc want an update?
> > > > > > 
> > > > > > Yes. lkml.kernel.org/r was the initial redirector, but lore is the new
> > > > > > thing.
> > > > > 
> > > > > FYI, lkml.kernel.org == lore.kernel.org in all respects. Using
> > > > > lore.kernel.org/r/<messageid> will match *any* mailing list archived at
> > > > > lore.kernel.org (for the full list, see https://lore.kernel.org/lists.html).
> > > > > I prefer people use lore.kernel.org because that name doesn't imply that the
> > > > > search will only match LKML.
> > > > 
> > > > I much prefer https://lkml.kernel.org/r/$msgid over lore, because I can
> > > > change it to marc.info with a single character change. And while lore
> > > > has improved, the thing is still a horrible horrible ugly site (an
> > > > actual fixed frame for the thread overview, and hiding that 'Reply
> > > > instructions' and 'LKML Archive on lore.kernel.org' somewhow would
> > > > already be a big improvement).
> > > 
> > > But lore allows to reference all mailinglists which are archived
> > > there, while lkml.k.org is hardcoded to lkml.
> > > 
> > > > Also, strlen("lkml.kernel.org/r/") < strlen("lore.kernel.org/lkml/").
> > > 
> > > Come on ....
> > 
> > If the size matters, how about just putting the message id?
> > Something like:
> >   Link: <alpine.DEB.2.21.1907010948310.1802@nanos.tec.linutronix.de>
> 
> We could add an option to `git am` to save the Message-ID automatically.

Kees already posted a simple git hook to add it to the message when
using `git am`.  I've been using it for a week or so already, works
wonderfully.

thanks,

greg k-h

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

[Linus Walleij]

On Wed, Jul 17, 2019 at 11:28 AM Greg KH <greg@kroah.com> wrote:
> On Wed, Jul 17, 2019 at 12:23:13PM +0300, Dan Carpenter wrote:

> > We could add an option to `git am` to save the Message-ID automatically.
>
> Kees already posted a simple git hook to add it to the message when
> using `git am`.  I've been using it for a week or so already, works
> wonderfully.

I also picked Kees script and it works like a charm as long as
you pick patches from a list that is stashed in lore.

Kees, you script is highly valuable, can we put it inside
Documentation/* somewhere?

Yours,
Linus Walleij

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

[Greg KH]

On Wed, Jul 17, 2019 at 06:09:40PM +0200, Linus Walleij wrote:
> On Wed, Jul 17, 2019 at 11:28 AM Greg KH <greg@kroah.com> wrote:
> > On Wed, Jul 17, 2019 at 12:23:13PM +0300, Dan Carpenter wrote:
> 
> > > We could add an option to `git am` to save the Message-ID automatically.
> >
> > Kees already posted a simple git hook to add it to the message when
> > using `git am`.  I've been using it for a week or so already, works
> > wonderfully.
> 
> I also picked Kees script and it works like a charm as long as
> you pick patches from a list that is stashed in lore.

Or, from a list that someday will be stashed in lore :)

I have an open request to get a few more missing lists into there, but
in the meantime, have been using the link already.

thanks,

greg k-h

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

[Linus Walleij]

On Wed, Jul 17, 2019 at 6:09 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Jul 17, 2019 at 11:28 AM Greg KH <greg@kroah.com> wrote:
> > On Wed, Jul 17, 2019 at 12:23:13PM +0300, Dan Carpenter wrote:
>
> > > We could add an option to `git am` to save the Message-ID automatically.
> >
> > Kees already posted a simple git hook to add it to the message when
> > using `git am`.  I've been using it for a week or so already, works
> > wonderfully.
>
> I also picked Kees script and it works like a charm as long as
> you pick patches from a list that is stashed in lore.

On popular request:
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-July/006608.html

Yours,
Linus Walleij

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

[Kees Cook]

On Wed, Jul 17, 2019 at 06:09:40PM +0200, Linus Walleij wrote:
> On Wed, Jul 17, 2019 at 11:28 AM Greg KH <greg@kroah.com> wrote:
> > On Wed, Jul 17, 2019 at 12:23:13PM +0300, Dan Carpenter wrote:
> 
> > > We could add an option to `git am` to save the Message-ID automatically.
> >
> > Kees already posted a simple git hook to add it to the message when
> > using `git am`.  I've been using it for a week or so already, works
> > wonderfully.
> 
> I also picked Kees script and it works like a charm as long as
> you pick patches from a list that is stashed in lore.
> 
> Kees, you script is highly valuable, can we put it inside
> Documentation/* somewhere?

Yeah, absolutely! Do we already have somewhere to put these kinds of
maintainer scripts? (Has Dan Williams already thought about this for
the maintainer's handbook?)

-- 
Kees Cook

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

[Joe Perches]

On Mon, 2019-07-22 at 10:02 -0700, Kees Cook wrote:
> On Wed, Jul 17, 2019 at 06:09:40PM +0200, Linus Walleij wrote:
> > On Wed, Jul 17, 2019 at 11:28 AM Greg KH <greg@kroah.com> wrote:
> > > On Wed, Jul 17, 2019 at 12:23:13PM +0300, Dan Carpenter wrote:
> > > > We could add an option to `git am` to save the Message-ID automatically.
> > > 
> > > Kees already posted a simple git hook to add it to the message when
> > > using `git am`.  I've been using it for a week or so already, works
> > > wonderfully.
> > 
> > I also picked Kees script and it works like a charm as long as
> > you pick patches from a list that is stashed in lore.
> > 
> > Kees, you script is highly valuable, can we put it inside
> > Documentation/* somewhere?
> 
> Yeah, absolutely! Do we already have somewhere to put these kinds of
> maintainer scripts? (Has Dan Williams already thought about this for
> the maintainer's handbook?)

scripts/ seems a more obvious choice.

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

[Steven Rostedt]

On Mon, 1 Jul 2019 09:49:56 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> > I much prefer https://lkml.kernel.org/r/$msgid over lore, because I can
> > change it to marc.info with a single character change. And while lore
> > has improved, the thing is still a horrible horrible ugly site (an
> > actual fixed frame for the thread overview, and hiding that 'Reply
> > instructions' and 'LKML Archive on lore.kernel.org' somewhow would
> > already be a big improvement).  
> 
> But lore allows to reference all mailinglists which are archived
> there, while lkml.k.org is hardcoded to lkml.

That's not true. For example:

 http://lkml.kernel.org/r/20190613122035.7d19f318@gandalf.local.home

Which ends up on the linux-rt-users list, and so does lore/r.

-- Steve

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

[Thomas Gleixner]

On Mon, 1 Jul 2019, Steven Rostedt wrote:

> On Mon, 1 Jul 2019 09:49:56 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > > I much prefer https://lkml.kernel.org/r/$msgid over lore, because I can
> > > change it to marc.info with a single character change. And while lore
> > > has improved, the thing is still a horrible horrible ugly site (an
> > > actual fixed frame for the thread overview, and hiding that 'Reply
> > > instructions' and 'LKML Archive on lore.kernel.org' somewhow would
> > > already be a big improvement).  
> > 
> > But lore allows to reference all mailinglists which are archived
> > there, while lkml.k.org is hardcoded to lkml.
> 
> That's not true. For example:
> 
>  http://lkml.kernel.org/r/20190613122035.7d19f318@gandalf.local.home
> 
> Which ends up on the linux-rt-users list, and so does lore/r.

That must be a recent enhancement.

Thanks,

	tglx

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

[Andrea Parri]

On Sun, Jun 30, 2019 at 12:31:20PM -0400, Konstantin Ryabitsev wrote:
> On Sat, Jun 29, 2019 at 05:16:18PM +0200, Thomas Gleixner wrote:
> >>Makes all sense to me.  One question/remark:
> >>
> >>Documentation/process/submitting-patches.rst says:
> >>
> >> "If the patch follows from a mailing list discussion, give a URL to the
> >>  mailing list archive; use the https://lkml.kernel.org/ redirector with
> >>  a ``Message-Id``, to ensure that the links cannot become stale."
> >>
> >>and it does not mention "lore.kernel.org": does this doc want an update?
> >
> >Yes. lkml.kernel.org/r was the initial redirector, but lore is the new
> >thing.
> 
> FYI, lkml.kernel.org == lore.kernel.org in all respects. Using
> lore.kernel.org/r/<messageid> will match *any* mailing list archived at
> lore.kernel.org (for the full list, see https://lore.kernel.org/lists.html).
> I prefer people use lore.kernel.org because that name doesn't imply that the
> search will only match LKML.

Thanks for this information, Konstantin.

I'm still a bit confused...  Consider, e.g., the following discussion:
it apparently forgot to include LKML, but the link  "works".

  https://lkml.kernel.org/r/20190131234012.3712779-1-ast@kernel.org

A last minute change?  What am I missing?

Thanks,
  Andrea

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

[Andrea Parri]

+Konstantin

On Mon, Jul 01, 2019 at 11:48:26AM +0200, Andrea Parri wrote:
> On Sun, Jun 30, 2019 at 12:31:20PM -0400, Konstantin Ryabitsev wrote:
> > On Sat, Jun 29, 2019 at 05:16:18PM +0200, Thomas Gleixner wrote:
> > >>Makes all sense to me.  One question/remark:
> > >>
> > >>Documentation/process/submitting-patches.rst says:
> > >>
> > >> "If the patch follows from a mailing list discussion, give a URL to the
> > >>  mailing list archive; use the https://lkml.kernel.org/ redirector with
> > >>  a ``Message-Id``, to ensure that the links cannot become stale."
> > >>
> > >>and it does not mention "lore.kernel.org": does this doc want an update?
> > >
> > >Yes. lkml.kernel.org/r was the initial redirector, but lore is the new
> > >thing.
> > 
> > FYI, lkml.kernel.org == lore.kernel.org in all respects. Using
> > lore.kernel.org/r/<messageid> will match *any* mailing list archived at
> > lore.kernel.org (for the full list, see https://lore.kernel.org/lists.html).
> > I prefer people use lore.kernel.org because that name doesn't imply that the
> > search will only match LKML.
> 
> Thanks for this information, Konstantin.
> 
> I'm still a bit confused...  Consider, e.g., the following discussion:
> it apparently forgot to include LKML, but the link  "works".
> 
>   https://lkml.kernel.org/r/20190131234012.3712779-1-ast@kernel.org
> 
> A last minute change?  What am I missing?
> 
> Thanks,
>   Andrea

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

[Leon Romanovsky]

On Sat, Jun 29, 2019 at 08:19:55AM +0200, Thomas Gleixner wrote:
> On Fri, 28 Jun 2019, 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.
>
> > 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"
> >
> > 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.
>
> What's really useful is when the commit has a Link tag:
>
>        https://lore.kernel.org/lkml/$MESSAGE-ID
>
> and if the submitters provide the same kind of link in their V(N)
> submission pointing to the V(N-1) in the cover letter:
>
>        https://lore.kernel.org/lkml/$MESSAGE-ID-V(N-1)
>
> If it's a single patch the link can be in the patch itself after the ---
> separator. That allows a quick lookup of the history.
>
> I also really want the change history to be at that place. i.e.
>
>  Subject ....
>
>  changelog text
>
>  Tags...
>  Signed-off-by: Joe Hacker
>
>  ---
>
>  V3: Fixed typo
>
>  V2: Made it work
>      https://lore.kernel.org/.... (if single patch)
>
>  ---
>
>  diffstat
>
>  ---
>
>  patch
>
> That way tools just strip the changes section away and the maintainer does
> not have to handle it manually.
>
> Can we pretty please agree on that format and make it mandatory?

Thomas,

Sorry for my naive question, but isn't it already standard way
to write patches with changelogs? At least from git era.

Thanks

>
> Thanks,
>
> 	tglx
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

[Geert Uytterhoeven]

Hi Leon,

On Tue, Jul 2, 2019 at 6:41 AM Leon Romanovsky <leon@kernel.org> wrote:
> On Sat, Jun 29, 2019 at 08:19:55AM +0200, Thomas Gleixner wrote:
> > On Fri, 28 Jun 2019, 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.
> >
> > > 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"
> > >
> > > 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.
> >
> > What's really useful is when the commit has a Link tag:
> >
> >        https://lore.kernel.org/lkml/$MESSAGE-ID
> >
> > and if the submitters provide the same kind of link in their V(N)
> > submission pointing to the V(N-1) in the cover letter:
> >
> >        https://lore.kernel.org/lkml/$MESSAGE-ID-V(N-1)
> >
> > If it's a single patch the link can be in the patch itself after the ---
> > separator. That allows a quick lookup of the history.
> >
> > I also really want the change history to be at that place. i.e.
> >
> >  Subject ....
> >
> >  changelog text
> >
> >  Tags...
> >  Signed-off-by: Joe Hacker
> >
> >  ---
> >
> >  V3: Fixed typo
> >
> >  V2: Made it work
> >      https://lore.kernel.org/.... (if single patch)
> >
> >  ---
> >
> >  diffstat
> >
> >  ---
> >
> >  patch
> >
> > That way tools just strip the changes section away and the maintainer does
> > not have to handle it manually.
> >
> > Can we pretty please agree on that format and make it mandatory?
>
> Thomas,
>
> Sorry for my naive question, but isn't it already standard way
> to write patches with changelogs? At least from git era.

Yes it is. But this thread is (or started) about preserving the patch
changelog in git history or not (i.e. including it above or below the
"---" in the emailed patch).

My personal stance: do not include it in the commit description, as
most/all of it doesn't matter for eternity.  If there is something
important to preserve (e.g. why an at first sight obvious alternative
wouldn't work), please do so in the patch description itself, not in the
changelog.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Leon Romanovsky]

On Tue, Jul 02, 2019 at 09:27:35AM +0200, Geert Uytterhoeven wrote:
> Hi Leon,
>
> On Tue, Jul 2, 2019 at 6:41 AM Leon Romanovsky <leon@kernel.org> wrote:
> > On Sat, Jun 29, 2019 at 08:19:55AM +0200, Thomas Gleixner wrote:
> > > On Fri, 28 Jun 2019, 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.
> > >
> > > > 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"
> > > >
> > > > 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.
> > >
> > > What's really useful is when the commit has a Link tag:
> > >
> > >        https://lore.kernel.org/lkml/$MESSAGE-ID
> > >
> > > and if the submitters provide the same kind of link in their V(N)
> > > submission pointing to the V(N-1) in the cover letter:
> > >
> > >        https://lore.kernel.org/lkml/$MESSAGE-ID-V(N-1)
> > >
> > > If it's a single patch the link can be in the patch itself after the ---
> > > separator. That allows a quick lookup of the history.
> > >
> > > I also really want the change history to be at that place. i.e.
> > >
> > >  Subject ....
> > >
> > >  changelog text
> > >
> > >  Tags...
> > >  Signed-off-by: Joe Hacker
> > >
> > >  ---
> > >
> > >  V3: Fixed typo
> > >
> > >  V2: Made it work
> > >      https://lore.kernel.org/.... (if single patch)
> > >
> > >  ---
> > >
> > >  diffstat
> > >
> > >  ---
> > >
> > >  patch
> > >
> > > That way tools just strip the changes section away and the maintainer does
> > > not have to handle it manually.
> > >
> > > Can we pretty please agree on that format and make it mandatory?
> >
> > Thomas,
> >
> > Sorry for my naive question, but isn't it already standard way
> > to write patches with changelogs? At least from git era.
>
> Yes it is. But this thread is (or started) about preserving the patch
> changelog in git history or not (i.e. including it above or below the
> "---" in the emailed patch).
>
> My personal stance: do not include it in the commit description, as
> most/all of it doesn't matter for eternity.  If there is something
> important to preserve (e.g. why an at first sight obvious alternative
> wouldn't work), please do so in the patch description itself, not in the
> changelog.

Fully agree, after patch is merged, I see no historical value in any
information provided by "changelog". At least for me, I'm looking
in git history while I'm debugging or developing new feature
and in those cases, I'm interested to see the final code and not
how many iterations this code passed prior to merge.

So if my voice is count, I'll vote against storing changelogs in git,
otherwise git logs will look less and less usable because of
distractions introduced by too much information.

BTW, I very liked the idea of automatic addition of "Link:" tag during
git am. It is extremely valuable tool to see corresponding patch series
without need to invest time in googling, which is not always reliable
or possible.

Thanks

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

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

[Takashi Iwai]

On Fri, 28 Jun 2019 22:51:03 +0200,
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. :-)
> 
> 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"
> 
> 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.

Agreed.  And I'm thinking whether we may have come consistent tag
for following the post discussions on ML archive.  Then the detailed
descriptions can be dropped from the changelog, and readers can still
follow easily.  e.g. the patch version change can be simply a
reference URL.


thanks,

Takashi

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

[Thomas Gleixner]

On Sat, 29 Jun 2019, Takashi Iwai wrote:
> On Fri, 28 Jun 2019 22:51:03 +0200,
> Luck, Tony wrote:
> > 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.
> 
> Agreed.  And I'm thinking whether we may have come consistent tag
> for following the post discussions on ML archive.  Then the detailed
> descriptions can be dropped from the changelog, and readers can still
> follow easily.  e.g. the patch version change can be simply a
> reference URL.

This tag exists today:

     Link: https://lore.kernel.org/lkml/MESSAGE-ID

my 'grab patches from list' scripts insert that tag automatically and it's
part of the commit changelog in git. That allows you to just jump to the
mail archive of the merged submission.

As I said in the other reply when the submitter has a link to the previous
submission in the cover letter or for a single patch without cover letter
in the patch itself, then following a discussion/revision chain becomes
trivial.

We'd just need to make that mandatory and I'm all for it.

Thanks,

	tglx

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

[Takashi Iwai]

On Sat, 29 Jun 2019 09:09:55 +0200,
Thomas Gleixner wrote:
> 
> On Sat, 29 Jun 2019, Takashi Iwai wrote:
> > On Fri, 28 Jun 2019 22:51:03 +0200,
> > Luck, Tony wrote:
> > > 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.
> > 
> > Agreed.  And I'm thinking whether we may have come consistent tag
> > for following the post discussions on ML archive.  Then the detailed
> > descriptions can be dropped from the changelog, and readers can still
> > follow easily.  e.g. the patch version change can be simply a
> > reference URL.
> 
> This tag exists today:
> 
>      Link: https://lore.kernel.org/lkml/MESSAGE-ID
> 
> my 'grab patches from list' scripts insert that tag automatically and it's
> part of the commit changelog in git. That allows you to just jump to the
> mail archive of the merged submission.
> 
> As I said in the other reply when the submitter has a link to the previous
> submission in the cover letter or for a single patch without cover letter
> in the patch itself, then following a discussion/revision chain becomes
> trivial.
> 
> We'd just need to make that mandatory and I'm all for it.

Right, we should push the wider usage of this tag.
I've used "Reference" tag and "BugLink" tag, and these look like
another common usages, but neither of them is found in documentation.
Maybe we should define a recommended tag for consistency and document
it properly.

BTW, can the URL be reached from patchwork?  That'd be really handy.


thanks,

Takashi

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

On Sat, Jun 29, 2019 at 09:18:28AM +0200, Takashi Iwai wrote:

> BTW, can the URL be reached from patchwork?  That'd be really handy.

Even better, could patchwork add it to the mboxes you download from it
like acks and so on?  Currently you can get the message ID so it's easy
to construct the link for things that are on LKML.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mauro Carvalho Chehab]

Em Sat, 29 Jun 2019 12:20:55 +0100
Mark Brown <broonie@kernel.org> escreveu:

> On Sat, Jun 29, 2019 at 09:18:28AM +0200, Takashi Iwai wrote:
> 
> > BTW, can the URL be reached from patchwork?  That'd be really handy.  
> 
> Even better, could patchwork add it to the mboxes you download from it
> like acks and so on?  Currently you can get the message ID so it's easy
> to construct the link for things that are on LKML.

I'm all for it, but the problem with patchwork is that the tool may be used 
on non-kernel development and/or the ML may not be in lore.

Also, there are more than one patchwork instance. We use our own for
Linux media (https://patchwork.linuxtv.org)[1].

On media, patchwork is used for both Kernel development and VDR
development (an userspace tool) - with is a completely unrelated
project (with different people behind it - and even a different mailing
list).

So, whatever change at patchwork should be done in a way that the
ML URL could be customized, and the new field would be added only
if the URL is not blank.

[1] long story short: back on the initial installs at kernel.org, patchwork 
didn't preserve IDs, due to some issue between master and mirrors - So, 
after using it for a while, we were forced to use our own instance that is
not replicated.


Thanks,
Mauro

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

[Andrew Donnellan]

On 1/7/19 2:01 am, Mauro Carvalho Chehab wrote:
> Em Sat, 29 Jun 2019 12:20:55 +0100
> Mark Brown <broonie@kernel.org> escreveu:
> 
>> On Sat, Jun 29, 2019 at 09:18:28AM +0200, Takashi Iwai wrote:
>>
>>> BTW, can the URL be reached from patchwork?  That'd be really handy.
>>
>> Even better, could patchwork add it to the mboxes you download from it
>> like acks and so on?  Currently you can get the message ID so it's easy
>> to construct the link for things that are on LKML.
> 
> I'm all for it, but the problem with patchwork is that the tool may be used
> on non-kernel development and/or the ML may not be in lore.
> 
> Also, there are more than one patchwork instance. We use our own for
> Linux media (https://patchwork.linuxtv.org)[1].
> 
> On media, patchwork is used for both Kernel development and VDR
> development (an userspace tool) - with is a completely unrelated
> project (with different people behind it - and even a different mailing
> list).
> 
> So, whatever change at patchwork should be done in a way that the
> ML URL could be customized, and the new field would be added only
> if the URL is not blank.

[+ patchwork list]

I'll have a go at adding a project/list-specific archive prefix and 
exposing that in the web interface.

Regarding adding it to downloaded mboxes, if we do that I'd like it to 
be a separate option. A single patch can also land in patchwork multiple 
times via various lists, so the URL will depend on which project you're 
looking at.

-- 
Andrew Donnellan              OzLabs, ADL Canberra
ajd@linux.ibm.com             IBM Australia Limited

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Mon, Jul 01, 2019 at 11:35:48AM +1000, Andrew Donnellan wrote:

> Regarding adding it to downloaded mboxes, if we do that I'd like it to be a
> separate option. A single patch can also land in patchwork multiple times
> via various lists, so the URL will depend on which project you're looking
> at.

At least for the kernel there's a redirector lore.kernel.org/r/msgid
which is list agnostic.  I'm not sure it matters much which of muiltiple
list archives get used though, if people really want this presumably
just having any old link should be enough.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Andrew Donnellan]

On 1/7/19 11:35 am, Andrew Donnellan wrote:
> On 1/7/19 2:01 am, Mauro Carvalho Chehab wrote:
>> Em Sat, 29 Jun 2019 12:20:55 +0100
>> Mark Brown <broonie@kernel.org> escreveu:
>>
>>> On Sat, Jun 29, 2019 at 09:18:28AM +0200, Takashi Iwai wrote:
>>>
>>>> BTW, can the URL be reached from patchwork?  That'd be really handy.
>>>
>>> Even better, could patchwork add it to the mboxes you download from it
>>> like acks and so on?  Currently you can get the message ID so it's easy
>>> to construct the link for things that are on LKML.
>>
>> I'm all for it, but the problem with patchwork is that the tool may be 
>> used
>> on non-kernel development and/or the ML may not be in lore.
>>
>> Also, there are more than one patchwork instance. We use our own for
>> Linux media (https://patchwork.linuxtv.org)[1].
>>
>> On media, patchwork is used for both Kernel development and VDR
>> development (an userspace tool) - with is a completely unrelated
>> project (with different people behind it - and even a different mailing
>> list).
>>
>> So, whatever change at patchwork should be done in a way that the
>> ML URL could be customized, and the new field would be added only
>> if the URL is not blank.
> 
> [+ patchwork list]
> 
> I'll have a go at adding a project/list-specific archive prefix and 
> exposing that in the web interface.

I've now submitted patches to add a mailing list archive link for each 
patch visible via the web interface and also via the REST API.

> Regarding adding it to downloaded mboxes, if we do that I'd like it to 
> be a separate option. A single patch can also land in patchwork multiple 
> times via various lists, so the URL will depend on which project you're 
> looking at.

Haven't done this bit yet.

-- 
Andrew Donnellan              OzLabs, ADL Canberra
ajd@linux.ibm.com             IBM Australia Limited

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

[Jiri Kosina]

On Sat, 29 Jun 2019, Thomas Gleixner wrote:

> This tag exists today:
> 
>      Link: https://lore.kernel.org/lkml/MESSAGE-ID
> 
> my 'grab patches from list' scripts insert that tag automatically and it's
> part of the commit changelog in git. That allows you to just jump to the
> mail archive of the merged submission.

Agreed, this tag is super-userful.

> As I said in the other reply when the submitter has a link to the previous
> submission in the cover letter or for a single patch without cover letter
> in the patch itself, then following a discussion/revision chain becomes
> trivial.
> 
> We'd just need to make that mandatory and I'm all for it.

Is anyone aware of a simple way how to let 'git-am' generate is 
automatically?

If not, I'll try to look into git sources and add an option for that.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[Sergey Senozhatsky]

On (07/01/19 11:05), Jiri Kosina wrote:
> 
> Is anyone aware of a simple way how to let 'git-am' generate is 
> automatically?

`git am -m' appends the patch's Message-ID to the commit message.
But it doesn't 'generate' one.

==
 m
 --message-id
 
    Pass the -m flag to git mailinfo (see git-mailinfo[1]), so
    that the Message-ID header is added to the commit message.
    The am.messageid configuration variable can be used to specify
    the default behaviour.
==

Or did you mean git format patch?

	-ss

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

[Michael Ellerman]

Thomas Gleixner <tglx@linutronix.de> writes:
> On Sat, 29 Jun 2019, Takashi Iwai wrote:
>> On Fri, 28 Jun 2019 22:51:03 +0200,
>> Luck, Tony wrote:
>> > 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.
>> 
>> Agreed.  And I'm thinking whether we may have come consistent tag
>> for following the post discussions on ML archive.  Then the detailed
>> descriptions can be dropped from the changelog, and readers can still
>> follow easily.  e.g. the patch version change can be simply a
>> reference URL.
>
> This tag exists today:
>
>      Link: https://lore.kernel.org/lkml/MESSAGE-ID
>
> my 'grab patches from list' scripts insert that tag automatically and it's
> part of the commit changelog in git. That allows you to just jump to the
> mail archive of the merged submission.

If you've got the link back to the mailing list archive, do you also
need Cc: tags in the change log?

It's always seemed to me they don't really add any value, they just tell
you that lots of people were Cc'ed on the patch and probably didn't have
time to review it :)

A couple of Cc: tags is no big deal, but sometimes they can get a bit
out of hand, eg. below.

cheers


commit 3599fe12a125fa7118da2bcc5033d7741fb5f3a1
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Apr 25 11:45:22 2019 +0200

    x86/stacktrace: Use common infrastructure
    
    Replace the stack_trace_save*() functions with the new arch_stack_walk()
    interfaces.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: linux-arch@vger.kernel.org
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: linux-mm@kvack.org
    Cc: David Rientjes <rientjes@google.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: kasan-dev@googlegroups.com
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Akinobu Mita <akinobu.mita@gmail.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: iommu@lists.linux-foundation.org
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Marek Szyprowski <m.szyprowski@samsung.com>
    Cc: Johannes Thumshirn <jthumshirn@suse.de>
    Cc: David Sterba <dsterba@suse.com>
    Cc: Chris Mason <clm@fb.com>
    Cc: Josef Bacik <josef@toxicpanda.com>
    Cc: linux-btrfs@vger.kernel.org
    Cc: dm-devel@redhat.com
    Cc: Mike Snitzer <snitzer@redhat.com>
    Cc: Alasdair Kergon <agk@redhat.com>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: intel-gfx@lists.freedesktop.org
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: David Airlie <airlied@linux.ie>
    Cc: Jani Nikula <jani.nikula@linux.intel.com>
    Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
    Cc: Miroslav Benes <mbenes@suse.cz>
    Link: https://lkml.kernel.org/r/20190425094803.816485461@linutronix.de

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

[Geert Uytterhoeven]

On Thu, Jul 4, 2019 at 2:22 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
> > On Sat, 29 Jun 2019, Takashi Iwai wrote:
> >> On Fri, 28 Jun 2019 22:51:03 +0200,
> >> Luck, Tony wrote:
> >> > 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.
> >>
> >> Agreed.  And I'm thinking whether we may have come consistent tag
> >> for following the post discussions on ML archive.  Then the detailed
> >> descriptions can be dropped from the changelog, and readers can still
> >> follow easily.  e.g. the patch version change can be simply a
> >> reference URL.
> >
> > This tag exists today:
> >
> >      Link: https://lore.kernel.org/lkml/MESSAGE-ID
> >
> > my 'grab patches from list' scripts insert that tag automatically and it's
> > part of the commit changelog in git. That allows you to just jump to the
> > mail archive of the merged submission.
>
> If you've got the link back to the mailing list archive, do you also
> need Cc: tags in the change log?
>
> It's always seemed to me they don't really add any value, they just tell
> you that lots of people were Cc'ed on the patch and probably didn't have
> time to review it :)

+1

Especially if the CC list was generated by blindly copying the output
from scripts/get_maintainer.pl, without passing through a common sense
filter.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Thomas Gleixner]

On Thu, 4 Jul 2019, Geert Uytterhoeven wrote:
> On Thu, Jul 4, 2019 at 2:22 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> > If you've got the link back to the mailing list archive, do you also
> > need Cc: tags in the change log?

Probably not.

> > It's always seemed to me they don't really add any value, they just tell
> > you that lots of people were Cc'ed on the patch and probably didn't have
> > time to review it :)
> 
> +1
> 
> Especially if the CC list was generated by blindly copying the output
> from scripts/get_maintainer.pl, without passing through a common sense
> filter.

And the maintainer then blindly picks it up :)

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

[Michael Ellerman]

Thomas Gleixner <tglx@linutronix.de> writes:
> On Thu, 4 Jul 2019, Geert Uytterhoeven wrote:
>> On Thu, Jul 4, 2019 at 2:22 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>> > If you've got the link back to the mailing list archive, do you also
>> > need Cc: tags in the change log?
>
> Probably not.
>
>> > It's always seemed to me they don't really add any value, they just tell
>> > you that lots of people were Cc'ed on the patch and probably didn't have
>> > time to review it :)
>> 
>> +1
>> 
>> Especially if the CC list was generated by blindly copying the output
>> from scripts/get_maintainer.pl, without passing through a common sense
>> filter.
>
> And the maintainer then blindly picks it up :)

Sorry to pick on you but I figure you can handle it :D

This is the kind of thing we should really have a script to check for,
so that maintainers don't have to think about it when committing.

cheers

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

[Michael Ellerman]

Michael Ellerman <mpe@ellerman.id.au> writes:
> Thomas Gleixner <tglx@linutronix.de> writes:
>> On Thu, 4 Jul 2019, Geert Uytterhoeven wrote:
>>> On Thu, Jul 4, 2019 at 2:22 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>> > If you've got the link back to the mailing list archive, do you also
>>> > need Cc: tags in the change log?
>>
>> Probably not.
>>
>>> > It's always seemed to me they don't really add any value, they just tell
>>> > you that lots of people were Cc'ed on the patch and probably didn't have
>>> > time to review it :)
>>> 
>>> +1
>>> 
>>> Especially if the CC list was generated by blindly copying the output
>>> from scripts/get_maintainer.pl, without passing through a common sense
>>> filter.
>>
>> And the maintainer then blindly picks it up :)
>
> Sorry to pick on you but I figure you can handle it :D
>
> This is the kind of thing we should really have a script to check for,
> so that maintainers don't have to think about it when committing.

Actually it looks like it's the tip bot adding these tags explicitly.
Compare the original submission:

  https://lore.kernel.org/lkml/20190425094803.816485461@linutronix.de/

vs the tip-bot reply:

  https://lore.kernel.org/lkml/tip-3599fe12a125fa7118da2bcc5033d7741fb5f3a1@git.kernel.org/


cheers

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

[Thomas Gleixner]

On Fri, 5 Jul 2019, Michael Ellerman wrote:
> Michael Ellerman <mpe@ellerman.id.au> writes:
> > Thomas Gleixner <tglx@linutronix.de> writes:
> >> On Thu, 4 Jul 2019, Geert Uytterhoeven wrote:
> >>> On Thu, Jul 4, 2019 at 2:22 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> >>> > If you've got the link back to the mailing list archive, do you also
> >>> > need Cc: tags in the change log?
> >>
> >> Probably not.
> >>
> >>> > It's always seemed to me they don't really add any value, they just tell
> >>> > you that lots of people were Cc'ed on the patch and probably didn't have
> >>> > time to review it :)
> >>> 
> >>> +1
> >>> 
> >>> Especially if the CC list was generated by blindly copying the output
> >>> from scripts/get_maintainer.pl, without passing through a common sense
> >>> filter.
> >>
> >> And the maintainer then blindly picks it up :)
> >
> > Sorry to pick on you but I figure you can handle it :D

I didn't feel offended :)

> > This is the kind of thing we should really have a script to check for,
> > so that maintainers don't have to think about it when committing.
> 
> Actually it looks like it's the tip bot adding these tags explicitly.
> Compare the original submission:
> 
>   https://lore.kernel.org/lkml/20190425094803.816485461@linutronix.de/
> 
> vs the tip-bot reply:
> 
>   https://lore.kernel.org/lkml/tip-3599fe12a125fa7118da2bcc5033d7741fb5f3a1@git.kernel.org/

No, it's my mbox to quilt script which does that for hysterical
raisins. Trivial to fix though.

IIRC git-am does the same, but I might be wrong as usual.

Thanks,

	tglx

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

[Geert Uytterhoeven]

Hi Thomas,

On Fri, Jul 5, 2019 at 8:28 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 5 Jul 2019, Michael Ellerman wrote:
> > Michael Ellerman <mpe@ellerman.id.au> writes:
> > > Thomas Gleixner <tglx@linutronix.de> writes:
> > >> On Thu, 4 Jul 2019, Geert Uytterhoeven wrote:
> > >>> On Thu, Jul 4, 2019 at 2:22 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> > >>> > If you've got the link back to the mailing list archive, do you also
> > >>> > need Cc: tags in the change log?
> > >>
> > >> Probably not.
> > >>
> > >>> > It's always seemed to me they don't really add any value, they just tell
> > >>> > you that lots of people were Cc'ed on the patch and probably didn't have
> > >>> > time to review it :)
> > >>>
> > >>> +1
> > >>>
> > >>> Especially if the CC list was generated by blindly copying the output
> > >>> from scripts/get_maintainer.pl, without passing through a common sense
> > >>> filter.
> > >>
> > >> And the maintainer then blindly picks it up :)
> > >
> > > Sorry to pick on you but I figure you can handle it :D
>
> I didn't feel offended :)
>
> > > This is the kind of thing we should really have a script to check for,
> > > so that maintainers don't have to think about it when committing.
> >
> > Actually it looks like it's the tip bot adding these tags explicitly.
> > Compare the original submission:
> >
> >   https://lore.kernel.org/lkml/20190425094803.816485461@linutronix.de/
> >
> > vs the tip-bot reply:
> >
> >   https://lore.kernel.org/lkml/tip-3599fe12a125fa7118da2bcc5033d7741fb5f3a1@git.kernel.org/
>
> No, it's my mbox to quilt script which does that for hysterical
> raisins. Trivial to fix though.
>
> IIRC git-am does the same, but I might be wrong as usual.

I'm happy to prove your last point ;-)

At least the version of git-am I'm using does not add Cc: tags based on
Cc: headers.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[James Bottomley]

On Thu, 2019-07-04 at 22:15 +1000, Michael Ellerman wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
> > On Sat, 29 Jun 2019, Takashi Iwai wrote:
> > > On Fri, 28 Jun 2019 22:51:03 +0200,
> > > Luck, Tony wrote:
> > > > 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.
> > > 
> > > Agreed.  And I'm thinking whether we may have come consistent tag
> > > for following the post discussions on ML archive.  Then the
> > > detailed
> > > descriptions can be dropped from the changelog, and readers can
> > > still
> > > follow easily.  e.g. the patch version change can be simply a
> > > reference URL.
> > 
> > This tag exists today:
> > 
> >      Link: https://lore.kernel.org/lkml/MESSAGE-ID
> > 
> > my 'grab patches from list' scripts insert that tag automatically
> > and it's part of the commit changelog in git. That allows you to
> > just jump to the mail archive of the merged submission.
> 
> If you've got the link back to the mailing list archive, do you also
> need Cc: tags in the change log?

Cc: tags are another git artefact.  They're how you tell git-send-email 
where to send copies of the patch for review or notice, but they don't
really provide any intrinsic historical value.

Perhaps we should alter the convention and say that if you're using
git-send-email and need a cc: list, then you should put all the cc tags
below the cutoff, say always at the bottom.  That way the version
information would be first, which is more important for the review, the
sender would preserve and show the cc list and it would be eliminated
on git-am.  Any cc tags that were necessary (like cc: stable) could go
above the cutoff.

James

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

[Michael Ellerman]

James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> On Thu, 2019-07-04 at 22:15 +1000, Michael Ellerman wrote:
>> Thomas Gleixner <tglx@linutronix.de> writes:
>> > On Sat, 29 Jun 2019, Takashi Iwai wrote:
>> > > On Fri, 28 Jun 2019 22:51:03 +0200,
>> > > Luck, Tony wrote:
>> > > > 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.
>> > > 
>> > > Agreed.  And I'm thinking whether we may have come consistent tag
>> > > for following the post discussions on ML archive.  Then the
>> > > detailed
>> > > descriptions can be dropped from the changelog, and readers can
>> > > still
>> > > follow easily.  e.g. the patch version change can be simply a
>> > > reference URL.
>> > 
>> > This tag exists today:
>> > 
>> >      Link: https://lore.kernel.org/lkml/MESSAGE-ID
>> > 
>> > my 'grab patches from list' scripts insert that tag automatically
>> > and it's part of the commit changelog in git. That allows you to
>> > just jump to the mail archive of the merged submission.
>> 
>> If you've got the link back to the mailing list archive, do you also
>> need Cc: tags in the change log?
>
> Cc: tags are another git artefact.  They're how you tell git-send-email 
> where to send copies of the patch for review or notice, but they don't
> really provide any intrinsic historical value.

Right, but it wasn't clear to me if anyone felt that they *do* have
historical value. Seems not.

> Perhaps we should alter the convention and say that if you're using
> git-send-email and need a cc: list, then you should put all the cc tags
> below the cutoff, say always at the bottom.  That way the version
> information would be first, which is more important for the review, the
> sender would preserve and show the cc list and it would be eliminated
> on git-am.  Any cc tags that were necessary (like cc: stable) could go
> above the cutoff.

Yeah that would be good. I'm not sure where the handling of Cc: tags is
really definitively documented.

There's some mention of Cc: here:

  https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

  If a person has had the opportunity to comment on a patch, but has not
  provided such comments, you may optionally add a Cc: tag to the patch.
  This is the only tag which might be added without an explicit action by
  the person it names - but it should indicate that this person was copied
  on the patch. This tag documents that potentially interested parties
  have been included in the discussion.

That does imply there is historical value in having the Cc: tags
committed, which I kind of disagree with.

So that maybe that needs a rewrite.

But lots of people aren't going to re-read the doc even if we update it,
so the immediate solution is for maintainers to strip superfluous Cc:
tags when committing.

Does anyone object to maintainers doing that?

cheers

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

[Alexandre Belloni]

On 05/07/2019 13:24:57+1000, Michael Ellerman wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> > Cc: tags are another git artefact.  They're how you tell git-send-email 
> > where to send copies of the patch for review or notice, but they don't
> > really provide any intrinsic historical value.
> 
> Right, but it wasn't clear to me if anyone felt that they *do* have
> historical value. Seems not.
> 

Some maintainers do think it is useful:

https://lore.kernel.org/lkml/20171128161014.GG27409@jhogan-linux.mipstec.com/


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[James Bottomley]

On Sat, 2019-07-06 at 16:02 +0200, Alexandre Belloni wrote:
> On 05/07/2019 13:24:57+1000, Michael Ellerman wrote:
> > James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> > > Cc: tags are another git artefact.  They're how you tell git-
> > > send-email 
> > > where to send copies of the patch for review or notice, but they
> > > don't
> > > really provide any intrinsic historical value.
> > 
> > Right, but it wasn't clear to me if anyone felt that they *do* have
> > historical value. Seems not.
> > 
> 
> Some maintainers do think it is useful:
> 
> https://lore.kernel.org/lkml/20171128161014.GG27409@jhogan-linux.mips
> tec.com/

Apart from stable, the only other cc I think is historically useful is
when I'm carrying a patch that impinges on another maintainer's tree
and they were cc'd for an ack which never arrived.  Then the cc in the
changelog tells Linus at least we tried.

James

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

[Michael Ellerman]

James Bottomley <James.Bottomley@HansenPartnership.com> writes:

> On Thu, 2019-07-04 at 22:15 +1000, Michael Ellerman wrote:
>> Thomas Gleixner <tglx@linutronix.de> writes:
>> > On Sat, 29 Jun 2019, Takashi Iwai wrote:
>> > > On Fri, 28 Jun 2019 22:51:03 +0200,
>> > > Luck, Tony wrote:
>> > > > 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.
>> > > 
>> > > Agreed.  And I'm thinking whether we may have come consistent tag
>> > > for following the post discussions on ML archive.  Then the
>> > > detailed
>> > > descriptions can be dropped from the changelog, and readers can
>> > > still
>> > > follow easily.  e.g. the patch version change can be simply a
>> > > reference URL.
>> > 
>> > This tag exists today:
>> > 
>> >      Link: https://lore.kernel.org/lkml/MESSAGE-ID
>> > 
>> > my 'grab patches from list' scripts insert that tag automatically
>> > and it's part of the commit changelog in git. That allows you to
>> > just jump to the mail archive of the merged submission.
>> 
>> If you've got the link back to the mailing list archive, do you also
>> need Cc: tags in the change log?
>
> Cc: tags are another git artefact.  They're how you tell git-send-email 
> where to send copies of the patch for review or notice, but they don't
> really provide any intrinsic historical value.
>
> Perhaps we should alter the convention and say that if you're using
> git-send-email and need a cc: list, then you should put all the cc tags
> below the cutoff, say always at the bottom.  That way the version
> information would be first, which is more important for the review, the
> sender would preserve and show the cc list and it would be eliminated
> on git-am.  Any cc tags that were necessary (like cc: stable) could go
> above the cutoff.

I just checked that this works with git send-email and it does. eg given:

  commit 7dcbcaee15ac44c8d62cfbaea2e5c8b7061fd29e
  Author:     Michael Ellerman <mpe@ellerman.id.au>
  AuthorDate: Fri Jul 5 13:32:47 2019 +1000
  
      Test commit
      
      Cc: above@somewhere.com
      Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
      ---
      Cc: below@somewhere.com


Then git send email works fine:

  $ git send-email --suppress-cc=self --to nowhere HEAD^
  /tmp/zxkuesD7QB/0001-Test-commit.patch
  (body) Adding cc: above@somewhere.com from line 'Cc: above@somewhere.com'
  (body) Adding cc: below@somewhere.com from line 'Cc: below@somewhere.com'
  
  From: Michael Ellerman <mpe@ellerman.id.au>
  To: nowhere
  Cc: above@somewhere.com,
          below@somewhere.com
  Subject: [PATCH] Test commit
  Date: Fri,  5 Jul 2019 13:39:40 +1000
  Message-Id: <20190705033940.32084-1-mpe@ellerman.id.au>
  X-Mailer: git-send-email 2.20.1


cheers

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

[Geert Uytterhoeven]

Hi James,

On Thu, Jul 4, 2019 at 4:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Thu, 2019-07-04 at 22:15 +1000, Michael Ellerman wrote:
> > Thomas Gleixner <tglx@linutronix.de> writes:
> > > On Sat, 29 Jun 2019, Takashi Iwai wrote:
> > > > On Fri, 28 Jun 2019 22:51:03 +0200,
> > > > Luck, Tony wrote:
> > > > > 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.
> > > >
> > > > Agreed.  And I'm thinking whether we may have come consistent tag
> > > > for following the post discussions on ML archive.  Then the
> > > > detailed
> > > > descriptions can be dropped from the changelog, and readers can
> > > > still
> > > > follow easily.  e.g. the patch version change can be simply a
> > > > reference URL.
> > >
> > > This tag exists today:
> > >
> > >      Link: https://lore.kernel.org/lkml/MESSAGE-ID
> > >
> > > my 'grab patches from list' scripts insert that tag automatically
> > > and it's part of the commit changelog in git. That allows you to
> > > just jump to the mail archive of the merged submission.
> >
> > If you've got the link back to the mailing list archive, do you also
> > need Cc: tags in the change log?
>
> Cc: tags are another git artefact.  They're how you tell git-send-email
> where to send copies of the patch for review or notice, but they don't
> really provide any intrinsic historical value.

Or you can use the --cc command line option.

One advantage of having it in the patches is when sending a big series,
and you don't want to Cc everyone on everything: you can control the Cc
field for individual patches.  But usually that leads to at least one
maintainer complaining he wasn't CCed on everything, or on the cover
letter. So better don't do that, and split your series.

> Perhaps we should alter the convention and say that if you're using
> git-send-email and need a cc: list, then you should put all the cc tags
> below the cutoff, say always at the bottom.  That way the version
> information would be first, which is more important for the review, the
> sender would preserve and show the cc list and it would be eliminated
> on git-am.  Any cc tags that were necessary (like cc: stable) could go
> above the cutoff.

Now Michael has verified that putting the Cc: list below the cutoff
works, I see the benefit of keeping it in the commits in your
development branch, just like the changelog: it avoids having to rerun
get_maintainers.pl (and common-sense-filter it) for each revised
submission.

But for series, you still have to take care manually of Cc's for the
cover letter. Unless you store that in git, too, with git commit
--allow-empty? Beware git rebase dropping empty commits!
Oh, there seems to be a --keep-empty option now?
But no corresponding git config option?
And it seems to come with its own caveats
https://stackoverflow.com/questions/45691594/empty-commits-removed-after-interactive-rebase-even-though-keep-empty-is-used

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[James Bottomley]

On Fri, 2019-06-28 at 14:11 -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.

It's always been the policy for most maintainers not to include these. 
They're usually context dependent like responses to reviews or how the
series changed because of testing or API changes.  Once they're placed
into history devoid of context they'll become a distraction rather than
useful information.

Conversely, if they do contain informative content that's about the
patch, not external context, that should have been placed into the
changelog.  So my other fear is that including version text will
encourage people not to update the original changelog leading to
potentially confusing changelogs requiring you to wade through all the
versioning information.

So I prefer we keep the current prevalent behaviour of removing the
version change information and making sure the relevant parts are
captured in the latest patch change log.

James

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

[David Howells]

Shuah Khan <skhan@linuxfoundation.org> 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.

I put the changelog in the cover note (ie. patch 0) since if there's more than
one patch there may well be changes that span multiple patches.  Whoever's
doing the merge could include this in the merge description.

David

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

[Thomas Gleixner]

On Mon, 1 Jul 2019, David Howells wrote:

> Shuah Khan <skhan@linuxfoundation.org> 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.
> 
> I put the changelog in the cover note (ie. patch 0) since if there's more than
> one patch there may well be changes that span multiple patches.  Whoever's

That's a pain. I'd have to go back and forth to find that information. If
the v$N info is in the patch itself, then it clearly shows what the scope
of the change is in that particular patch, e.g. just fixing up the typo or
some structural change.

And no, this is not about convenience for the submitter. It's about
convenience for the reviewer/maintainer. The goal must be to make their
life as simple as possible not the other way round.

> doing the merge could include this in the merge description.

That does not help for patch series which are applied directly from mail.

Thanks,

	tglx

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

[Laurent Pinchart]

Hi Thomas,

On Mon, Jul 01, 2019 at 05:40:58PM +0200, Thomas Gleixner wrote:
> On Mon, 1 Jul 2019, David Howells wrote:
> > Shuah Khan <skhan@linuxfoundation.org> 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.
> > 
> > I put the changelog in the cover note (ie. patch 0) since if there's more than
> > one patch there may well be changes that span multiple patches.  Whoever's
> 
> That's a pain. I'd have to go back and forth to find that information. If
> the v$N info is in the patch itself, then it clearly shows what the scope
> of the change is in that particular patch, e.g. just fixing up the typo or
> some structural change.

I agree with you in general (I've asked multiple submitters to move
changelogs to individual patches in the past), except for high-level
change descriptions at the series level that don't naturally fit in one
particular patch. I tend myself to summarise the most important changes
in the cover letter, so someone reviewing the whole series will have a
global view of the changes at the beginning, and will also find the
relevant information in each patch. I however understand that this is
possibly more work for the submitter and my thus get frowned upon, but
I find it useful during review.

> And no, this is not about convenience for the submitter. It's about
> convenience for the reviewer/maintainer. The goal must be to make their
> life as simple as possible not the other way round.
> 
> > doing the merge could include this in the merge description.
> 
> That does not help for patch series which are applied directly from mail.

-- 
Regards,

Laurent Pinchart

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

[James Bottomley]

On Mon, 2019-07-01 at 17:40 +0200, Thomas Gleixner wrote:
> On Mon, 1 Jul 2019, David Howells wrote:
> 
> > Shuah Khan <skhan@linuxfoundation.org> 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.
> > 
> > I put the changelog in the cover note (ie. patch 0) since if
> > there's more than one patch there may well be changes that span
> > multiple patches.  Whoever's
> 
> That's a pain. I'd have to go back and forth to find that
> information. If the v$N info is in the patch itself, then it clearly
> shows what the scope of the change is in that particular patch, e.g.
> just fixing up the typo or some structural change.
> 
> And no, this is not about convenience for the submitter. It's about
> convenience for the reviewer/maintainer. The goal must be to make
> their life as simple as possible not the other way round.

Wouldn't the contemporaneous reviewer/maintainer be on the actual email
threads ... so they wouldn't need the references?

I see the Link tag as a useful historical artifact but you seem to
think it's an essential part of the contemporaneous acceptance.  I've
definitely been in the situation of having to find patches and
discussion (usually when next or 0day informs us of a SCSI breakage
that wasn't sent to our list and I have to find the original to take a
look) but really, it's not a common occurrence so it's not a huge
burden to have to use a search facility to find the patch and
discussion on the list it was originally sent to.

My general impression is that for me it's not contemporaneously very
useful and cregit seems to cover the historical part, so I'm
ambivalent about including a Link tag and definitely wouldn't require
it.

James


> > doing the merge could include this in the merge description.
> 
> That does not help for patch series which are applied directly from
> mail.
> 
> Thanks,
> 
> 	tglx
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

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

[Thomas Gleixner]

On Mon, 1 Jul 2019, James Bottomley wrote:
> On Mon, 2019-07-01 at 17:40 +0200, Thomas Gleixner wrote:
> > On Mon, 1 Jul 2019, David Howells wrote:
> > > I put the changelog in the cover note (ie. patch 0) since if
> > > there's more than one patch there may well be changes that span
> > > multiple patches.  Whoever's
> > 
> > That's a pain. I'd have to go back and forth to find that
> > information. If the v$N info is in the patch itself, then it clearly
> > shows what the scope of the change is in that particular patch, e.g.
> > just fixing up the typo or some structural change.
> > 
> > And no, this is not about convenience for the submitter. It's about
> > convenience for the reviewer/maintainer. The goal must be to make
> > their life as simple as possible not the other way round.
> 
> Wouldn't the contemporaneous reviewer/maintainer be on the actual email
> threads ... so they wouldn't need the references?
> 
> I see the Link tag as a useful historical artifact but you seem to
> think it's an essential part of the contemporaneous acceptance.  I've

That's not what I was talking about. This was about a per patch change
history vs. putting all changes fron the previous version into the cover
letter.

i.e.

	cover letter

	V2 -> V3:
	      - list of changes

vs.

	cover letter

	V2 -> V3:
	   High level overview of changes

  and
	patch b/m

	SOB
	---
	V3: Fixup up typo

	patch d/m

	SOB
	---
	V3: New algorithm

	patch f/m

	SOB
	---
	V2: Fix comment style


So on review I can (if I trust the submitter) just skip 'b' and 'f' because
'b' has no interesting change (i.e. the typo which made the compile fail is
fixed) and 'f' has no change at all. Instead I focus on 'd' because there
is the meat of the V3 submission.

Having all this information only in the cover letter is a pain especially
on larger patch series.

The link to V2 is in both cases in the cover letter. That's
sufficient. Yes, it might not be necessary, but I just recently ended up
wasting an hour finding an earlier version because the cover letter subject
changed slightly. I surely have better things to do.

Thanks,

	tglx





	
	

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

[James Bottomley]

On Mon, 2019-07-01 at 19:54 +0200, Thomas Gleixner wrote:
> On Mon, 1 Jul 2019, James Bottomley wrote:
> > On Mon, 2019-07-01 at 17:40 +0200, Thomas Gleixner wrote:
> > > On Mon, 1 Jul 2019, David Howells wrote:
> > > > I put the changelog in the cover note (ie. patch 0) since if
> > > > there's more than one patch there may well be changes that span
> > > > multiple patches.  Whoever's
> > > 
> > > That's a pain. I'd have to go back and forth to find that
> > > information. If the v$N info is in the patch itself, then it
> > > clearly shows what the scope of the change is in that particular
> > > patch, e.g. just fixing up the typo or some structural change.
> > > 
> > > And no, this is not about convenience for the submitter. It's
> > > about convenience for the reviewer/maintainer. The goal must be
> > > to make their life as simple as possible not the other way round.
> > 
> > Wouldn't the contemporaneous reviewer/maintainer be on the actual
> > email threads ... so they wouldn't need the references?
> > 
> > I see the Link tag as a useful historical artifact but you seem to
> > think it's an essential part of the contemporaneous
> > acceptance.  I've
> 
> That's not what I was talking about. This was about a per patch
> change history vs. putting all changes fron the previous version into
> the cover letter.
> 
> i.e.
> 
> 	cover letter
> 
> 	V2 -> V3:
> 	      - list of changes
> 
> vs.
> 
> 	cover letter
> 
> 	V2 -> V3:
> 	   High level overview of changes
> 
>   and
> 	patch b/m
> 
> 	SOB
> 	---
> 	V3: Fixup up typo
> 
> 	patch d/m
> 
> 	SOB
> 	---
> 	V3: New algorithm
> 
> 	patch f/m
> 
> 	SOB
> 	---
> 	V2: Fix comment style
> 
> 
> So on review I can (if I trust the submitter) just skip 'b' and 'f'
> because 'b' has no interesting change (i.e. the typo which made the
> compile fail is fixed) and 'f' has no change at all. Instead I focus
> on 'd' because there is the meat of the V3 submission.
> 
> Having all this information only in the cover letter is a pain
> especially on larger patch series.
> 
> The link to V2 is in both cases in the cover letter. That's
> sufficient. Yes, it might not be necessary, but I just recently ended
> up wasting an hour finding an earlier version because the cover
> letter subject changed slightly. I surely have better things to do.

I'm not arguing against changelogs in the patches themselves as long as
they're below the commit message --- cutoff.  In fact I think that's
best practice for reviewers.  I'm just arguing making a link tag
mandatory would impose an enforcement burden on a lot of subsystems
which would provide no benefit to them), so I don't mind it's being
optional but it shouldn't be mandatory.

James

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

[Thomas Gleixner]

On Tue, 2 Jul 2019, James Bottomley wrote:
> On Mon, 2019-07-01 at 19:54 +0200, Thomas Gleixner wrote:
> > The link to V2 is in both cases in the cover letter. That's
> > sufficient. Yes, it might not be necessary, but I just recently ended
> > up wasting an hour finding an earlier version because the cover
> > letter subject changed slightly. I surely have better things to do.
> 
> I'm not arguing against changelogs in the patches themselves as long as
> they're below the commit message --- cutoff.  In fact I think that's
> best practice for reviewers.  I'm just arguing making a link tag
> mandatory would impose an enforcement burden on a lot of subsystems
> which would provide no benefit to them), so I don't mind it's being
> optional but it shouldn't be mandatory.

What's the burden exactly?

You mean that people would have to add them manually?

People who use the link tag today have their homebrewn scripts to add them
automatically and it shouldn't be rocket science to add that to git,
patchwork whatever.

Thanks,

	tglx

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

[James Bottomley]

On Tue, 2019-07-02 at 16:49 +0200, Thomas Gleixner wrote:
> On Tue, 2 Jul 2019, James Bottomley wrote:
> > On Mon, 2019-07-01 at 19:54 +0200, Thomas Gleixner wrote:
> > > The link to V2 is in both cases in the cover letter. That's
> > > sufficient. Yes, it might not be necessary, but I just recently
> > > ended up wasting an hour finding an earlier version because the
> > > cover letter subject changed slightly. I surely have better
> > > things to do.
> > 
> > I'm not arguing against changelogs in the patches themselves as
> > long as they're below the commit message --- cutoff.  In fact I
> > think that's best practice for reviewers.  I'm just arguing making
> > a link tag mandatory would impose an enforcement burden on a lot of
> > subsystems which would provide no benefit to them), so I don't mind
> > it's being optional but it shouldn't be mandatory.
> 
> What's the burden exactly?

Not everyone knows what a message ID is or how to find it, so we'd have
to explain why the patch was rejected (or simply have the maintainer
add it at commit time, which currently involves some effort).  Quite a
few of the list archives mangle it so someone would have to notice this
or unmangle it.

> You mean that people would have to add them manually?

Most email tools don't show you the msgid, so if you're simply doing
driveby commits now we have to explain to you how to find it ...
remember linux-scsi isn't currently on lore so we can't just say "use
the lore archive".

There's also a knock on: for this to be useful, the commit series needs
to be threaded.  I've actually no objection to making this one
mandatory I'm just noting it's another precursor we need to think
about.

> People who use the link tag today have their homebrewn scripts to add
> them automatically and it shouldn't be rocket science to add that to
> git, patchwork whatever.

So if we find a way of automating this globally, I'm completely happy. 
However, I would also note that whatever script does this could likely
also be run by you after the fact to generate the back link, so
foolproof automation also lessens the need to make this a mandatory
commit tag.

James

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

[James Bottomley]

On Tue, 2019-07-02 at 08:10 -0700, James Bottomley wrote:
> On Tue, 2019-07-02 at 16:49 +0200, Thomas Gleixner wrote:
[...]
> > People who use the link tag today have their homebrewn scripts to
> > add them automatically and it shouldn't be rocket science to add
> > that to git, patchwork whatever.
> 
> So if we find a way of automating this globally, I'm completely
> happy. However, I would also note that whatever script does this
> could likely also be run by you after the fact to generate the back
> link, so foolproof automation also lessens the need to make this a
> mandatory commit tag.

Just on this one, it looks like getting git to archive the msgid of the
patch commit would assist any script that goes off and tries to find
patch series and its precursors in the archives, so perhaps adding that
would be the actionable change in all of this?

James

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

[Shuah Khan]

On 7/2/19 9:18 AM, James Bottomley wrote:
> On Tue, 2019-07-02 at 08:10 -0700, James Bottomley wrote:
>> On Tue, 2019-07-02 at 16:49 +0200, Thomas Gleixner wrote:
> [...]
>>> People who use the link tag today have their homebrewn scripts to
>>> add them automatically and it shouldn't be rocket science to add
>>> that to git, patchwork whatever.
>>
>> So if we find a way of automating this globally, I'm completely
>> happy. However, I would also note that whatever script does this
>> could likely also be run by you after the fact to generate the back
>> link, so foolproof automation also lessens the need to make this a
>> mandatory commit tag.
> 
> Just on this one, it looks like getting git to archive the msgid of the
> patch commit would assist any script that goes off and tries to find
> patch series and its precursors in the archives, so perhaps adding that
> would be the actionable change in all of this?
> 

Looks like two things are emerging from my original thread that aimed to
get clarification on including "Patch revision information" in commit
logs.

1. Judiciously including information from the "Patch revision info."
    in the commit log could be valuable. Don't just bloat the commit
    log with trivial change history. This is part of patch review
    process and will not require any scripting. Maybe an update to
    the patch submit guidelines documents.

2. Archiving msgid of the patch commit for reference. This one would
    require some scripting to make it easier for maintainers.

There two aren't mutually exclusive and are actionable. Let's distill
the thread discussion to the above two items as we discuss further.

thanks,
-- Shuah

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

[James Bottomley]

On Tue, 2019-07-02 at 09:39 -0600, Shuah Khan wrote:
> On 7/2/19 9:18 AM, James Bottomley wrote:
> > On Tue, 2019-07-02 at 08:10 -0700, James Bottomley wrote:
> > > On Tue, 2019-07-02 at 16:49 +0200, Thomas Gleixner wrote:
> > 
> > [...]
> > > > People who use the link tag today have their homebrewn scripts
> > > > to add them automatically and it shouldn't be rocket science to
> > > > add that to git, patchwork whatever.
> > > 
> > > So if we find a way of automating this globally, I'm completely
> > > happy. However, I would also note that whatever script does this
> > > could likely also be run by you after the fact to generate the
> > > back link, so foolproof automation also lessens the need to make
> > > this a mandatory commit tag.
> > 
> > Just on this one, it looks like getting git to archive the msgid of
> > the patch commit would assist any script that goes off and tries to
> > find patch series and its precursors in the archives, so perhaps
> > adding that would be the actionable change in all of this?
> > 
> 
> Looks like two things are emerging from my original thread that aimed
> to get clarification on including "Patch revision information" in
> commit logs.
> 
> 1. Judiciously including information from the "Patch revision info."
>     in the commit log could be valuable. Don't just bloat the commit
>     log with trivial change history. This is part of patch review
>     process and will not require any scripting. Maybe an update to
>     the patch submit guidelines documents.

Agree, as long as it's what Thomas and I have been discussing: namely
keeping the version information below the --- permanent history cutoff,
so it's visible to reviewers but won't become part of the permanent
patch history when the patch is committed to git.

I think the bit we're still arguing about is the link to prior series
as part of this below the line version history.  I agree it's useful,
but I also think it would be a burden to enforce for every patch
series.

> 2. Archiving msgid of the patch commit for reference. This one would
>     require some scripting to make it easier for maintainers.

Yes, I think we all agree on this.  The real question is how.  If we
make git do it, I think trivially Message-Id: can become part of the
optional metadata.  Or we could all use commit hooks that add a link
tag.  Personally I prefer the former because it would be universally
done with no effort but I recognise it would take time to get the
ecosystem change to propagate.

James

> There two aren't mutually exclusive and are actionable. Let's distill
> the thread discussion to the above two items as we discuss further.
> 
> thanks,
> -- Shuah
> 
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

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

[Kees Cook]

On Tue, Jul 02, 2019 at 08:51:53AM -0700, James Bottomley wrote:
> Yes, I think we all agree on this.  The real question is how.  If we
> make git do it, I think trivially Message-Id: can become part of the
> optional metadata.  Or we could all use commit hooks that add a link
> tag.  Personally I prefer the former because it would be universally
> done with no effort but I recognise it would take time to get the
> ecosystem change to propagate.

I think this should be easy to implement in a general way. I suspect
there wouldn't be much love for hard-coding the details, though, so
maybe it would require per-developer git configuration. I imagine a
general mapping would need to be:

list_email -> archive_url

i.e. if "$list_email" is in the To/Cc, then "git am" can easily insert
the Message-Id into the "$archive_url". For example:

linux-kernel@vger.kernel.org -> https://lkml.kernel.org/r/%s

-- 
Kees Cook

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

[Konstantin Ryabitsev]

On Tue, Jul 02, 2019 at 09:30:34AM -0700, Kees Cook wrote:
>On Tue, Jul 02, 2019 at 08:51:53AM -0700, James Bottomley wrote:
>> Yes, I think we all agree on this.  The real question is how.  If we
>> make git do it, I think trivially Message-Id: can become part of the
>> optional metadata.  Or we could all use commit hooks that add a link
>> tag.  Personally I prefer the former because it would be universally
>> done with no effort but I recognise it would take time to get the
>> ecosystem change to propagate.
>
>I think this should be easy to implement in a general way. I suspect
>there wouldn't be much love for hard-coding the details, though, so
>maybe it would require per-developer git configuration. I imagine a
>general mapping would need to be:
>
>list_email -> archive_url
>
>i.e. if "$list_email" is in the To/Cc, then "git am" can easily insert
>the Message-Id into the "$archive_url". For example:
>
>linux-kernel@vger.kernel.org -> https://lkml.kernel.org/r/%s

BTW, if you are a mutt user, there's this handy tool that will 
automatically display canonical links to lore.kernel.org for every 
message that comes from a mailing list archived there:

https://github.com/danrue/lorifier


-K

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

[James Bottomley]

On Tue, 2019-07-02 at 09:30 -0700, Kees Cook wrote:
> On Tue, Jul 02, 2019 at 08:51:53AM -0700, James Bottomley wrote:
> > Yes, I think we all agree on this.  The real question is how.  If
> > we make git do it, I think trivially Message-Id: can become part of
> > the optional metadata.  Or we could all use commit hooks that add a
> > link tag.  Personally I prefer the former because it would be
> > universally done with no effort but I recognise it would take time
> > to get the ecosystem change to propagate.
> 
> I think this should be easy to implement in a general way. I suspect
> there wouldn't be much love for hard-coding the details, though, so
> maybe it would require per-developer git configuration. I imagine a
> general mapping would need to be:
> 
> list_email -> archive_url
> 
> i.e. if "$list_email" is in the To/Cc, then "git am" can easily
> insert the Message-Id into the "$archive_url". For example:
> 
> linux-kernel@vger.kernel.org -> https://lkml.kernel.org/r/%s

I don't want to admit to being the sucker who actually looking into
coding this today, so shall we just say I learned through "contacts"
that git already has this feature:

---
commit a078f7321b02eb945b63804a80b0ba52c9da4ed3
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Nov 25 15:00:56 2014 +0100

    git-am: add --message-id/--no-message-id
---

It's not quite as we would wish: it adds a 

Message-ID: <ID>

Tag to the commit.  For some reason its undocumented, but it's been
there since version 2.3.0.  I realise the format isn't what we've been
discussing, but if it's there we can use it ... and since it's in a
pretty early version we can all use it now.

James

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

[Thomas Gleixner]

On Tue, 2 Jul 2019, James Bottomley wrote:

> On Tue, 2019-07-02 at 09:30 -0700, Kees Cook wrote:
> > On Tue, Jul 02, 2019 at 08:51:53AM -0700, James Bottomley wrote:
> > > Yes, I think we all agree on this.  The real question is how.  If
> > > we make git do it, I think trivially Message-Id: can become part of
> > > the optional metadata.  Or we could all use commit hooks that add a
> > > link tag.  Personally I prefer the former because it would be
> > > universally done with no effort but I recognise it would take time
> > > to get the ecosystem change to propagate.
> > 
> > I think this should be easy to implement in a general way. I suspect
> > there wouldn't be much love for hard-coding the details, though, so
> > maybe it would require per-developer git configuration. I imagine a
> > general mapping would need to be:
> > 
> > list_email -> archive_url
> > 
> > i.e. if "$list_email" is in the To/Cc, then "git am" can easily
> > insert the Message-Id into the "$archive_url". For example:
> > 
> > linux-kernel@vger.kernel.org -> https://lkml.kernel.org/r/%s
> 
> I don't want to admit to being the sucker who actually looking into
> coding this today, so shall we just say I learned through "contacts"
> that git already has this feature:
> 
> ---
> commit a078f7321b02eb945b63804a80b0ba52c9da4ed3
> Author: Paolo Bonzini <pbonzini@redhat.com>
> Date:   Tue Nov 25 15:00:56 2014 +0100
> 
>     git-am: add --message-id/--no-message-id
> ---
> 
> It's not quite as we would wish: it adds a 
> 
> Message-ID: <ID>
> 
> Tag to the commit.  For some reason its undocumented, but it's been
> there since version 2.3.0.  I realise the format isn't what we've been
> discussing, but if it's there we can use it ... and since it's in a
> pretty early version we can all use it now.

Please no.

If we allow Message-ID just because git has that undocumented feature, then
we open the door for the next undocumented tag because XYZ has that other
magic feature which creates 'This patch was sent with $Message-Id: <ID>'.

We really don't want yet another version of tag for that purpose. The
'Link:' tag is documented and proven to be useful.

Thanks,

	tglx

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

[James Bottomley]

On Wed, 2019-07-03 at 00:07 +0200, Thomas Gleixner wrote:
> On Tue, 2 Jul 2019, James Bottomley wrote:
> 
> > On Tue, 2019-07-02 at 09:30 -0700, Kees Cook wrote:
> > > On Tue, Jul 02, 2019 at 08:51:53AM -0700, James Bottomley wrote:
> > > > Yes, I think we all agree on this.  The real question is
> > > > how.  If we make git do it, I think trivially Message-Id: can
> > > > become part of the optional metadata.  Or we could all use
> > > > commit hooks that add a link tag.  Personally I prefer the
> > > > former because it would be universally done with no effort but
> > > > I recognise it would take time to get the ecosystem change to
> > > > propagate.
> > > 
> > > I think this should be easy to implement in a general way. I
> > > suspect there wouldn't be much love for hard-coding the details,
> > > though, so maybe it would require per-developer git
> > > configuration. I imagine a general mapping would need to be:
> > > 
> > > list_email -> archive_url
> > > 
> > > i.e. if "$list_email" is in the To/Cc, then "git am" can easily
> > > insert the Message-Id into the "$archive_url". For example:
> > > 
> > > linux-kernel@vger.kernel.org -> https://lkml.kernel.org/r/%s
> > 
> > I don't want to admit to being the sucker who actually looking into
> > coding this today, so shall we just say I learned through
> > "contacts" that git already has this feature:
> > 
> > ---
> > commit a078f7321b02eb945b63804a80b0ba52c9da4ed3
> > Author: Paolo Bonzini <pbonzini@redhat.com>
> > Date:   Tue Nov 25 15:00:56 2014 +0100
> > 
> >     git-am: add --message-id/--no-message-id
> > ---
> > 
> > It's not quite as we would wish: it adds a 
> > 
> > Message-ID: <ID>
> > 
> > Tag to the commit.  For some reason its undocumented, but it's been
> > there since version 2.3.0.  I realise the format isn't what we've
> > been discussing, but if it's there we can use it ... and since it's
> > in a pretty early version we can all use it now.
> 
> Please no.
> 
> If we allow Message-ID just because git has that undocumented
> feature,

Actually, documentation was added in a later version, so in my 2.13 git
it's there.  It even has a config option to turn it on

am.messageid = 1

>  then we open the door for the next undocumented tag because XYZ has
> that other magic feature which creates 'This patch was sent with
> $Message-Id: <ID>'.

git is our upstream for version control and our upstream has already
had this as a feature since 2014.  Trying to go to upstream  5 years
later and ask them to change it is likely going to be a singularly
unsuccessful exercise, plus even in the unlikely event we can work out
how to do it compatibly and without causing confusion and upstream said
yes it would take another few years to propagate.

> We really don't want yet another version of tag for that purpose. The
> 'Link:' tag is documented and proven to be useful.

You were the one pushing this, do you really want to hold it up because
what's available isn't exactly what you want?

What's wrong with Kees' suggestion that we add a new config option to
determine how we display the tag?  The information is basically there
so a Message-Id: tag can be converted to any type of Link: tag you
like.

I'm going to be a lot more successful going to the git upstream and
saying we've already been using a Link tag for a while, so we'd like
your message-id to appear as a Link: for compatibility than I am going
to be to try to get them to add a Link: tag ...

James

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

[Theodore Ts'o]

On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> git is our upstream for version control and our upstream has already
> had this as a feature since 2014.  Trying to go to upstream  5 years
> later and ask them to change it is likely going to be a singularly
> unsuccessful exercise, plus even in the unlikely event we can work out
> how to do it compatibly and without causing confusion and upstream said
> yes it would take another few years to propagate.

If we really want to use the Link: header, we should be able to do
this without requiring any changes to git.

Step 1)   git config am.messageid true
Step 2)   Write and install a .git/hooks/applypatch-msg script which
	  looks for Message-Id: and transmogrifies that line to a
	  Link: trailer, using the lore.kernel.org URL template
Step 3)   Document this in Documentation/process.  For bonus points
	  create a script which automatically sets up the user's git
	  configuration by setting up am.messageid config and
	  installing the hook file.
Step 4)   Profit

						- Ted

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

[Thomas Gleixner]

On Tue, 2 Jul 2019, Theodore Ts'o wrote:
> On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> > git is our upstream for version control and our upstream has already
> > had this as a feature since 2014.  Trying to go to upstream  5 years
> > later and ask them to change it is likely going to be a singularly
> > unsuccessful exercise, plus even in the unlikely event we can work out
> > how to do it compatibly and without causing confusion and upstream said
> > yes it would take another few years to propagate.
> 
> If we really want to use the Link: header, we should be able to do
> this without requiring any changes to git.
> 
> Step 1)   git config am.messageid true
> Step 2)   Write and install a .git/hooks/applypatch-msg script which
> 	  looks for Message-Id: and transmogrifies that line to a
> 	  Link: trailer, using the lore.kernel.org URL template
> Step 3)   Document this in Documentation/process.  For bonus points
> 	  create a script which automatically sets up the user's git
> 	  configuration by setting up am.messageid config and
> 	  installing the hook file.
> Step 4)   Profit

Amen.

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

[Ralf Ramsauer]

Hi Thomas,

On 7/3/19 12:49 AM, Thomas Gleixner wrote:
> On Tue, 2 Jul 2019, Theodore Ts'o wrote:
>> On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
>>> git is our upstream for version control and our upstream has already
>>> had this as a feature since 2014.  Trying to go to upstream  5 years
>>> later and ask them to change it is likely going to be a singularly
>>> unsuccessful exercise, plus even in the unlikely event we can work out
>>> how to do it compatibly and without causing confusion and upstream said
>>> yes it would take another few years to propagate.
>>
>> If we really want to use the Link: header, we should be able to do
>> this without requiring any changes to git.
>>
>> Step 1)   git config am.messageid true
>> Step 2)   Write and install a .git/hooks/applypatch-msg script which
>> 	  looks for Message-Id: and transmogrifies that line to a
>> 	  Link: trailer, using the lore.kernel.org URL template
>> Step 3)   Document this in Documentation/process.  For bonus points
>> 	  create a script which automatically sets up the user's git
>> 	  configuration by setting up am.messageid config and
>> 	  installing the hook file.
>> Step 4)   Profit
> 
> Amen.
Unfortunately, Message-IDs aren't unique. People sometimes like to reuse
old Message-IDs, mails may be sent to several lists and are modified by
lists servers (footers, encoding, additional headers). So the Message-ID
per-se isn't a stable indicator which exact message is referenced.

Anyway, in most cases Message-IDs should be good enough for a mapping,
and including Message-IDs in commit messages is a good idea in many regards.

I'm working on PaStA [1], a tool that automatically maps Message-IDs on
lists to commit hashes in repositories with pretty high accuracy. It's
part of a research project at the Technical University of Applied
Sciences Regensburg. For those interested in the method and how it
works, see [2].

Thomas, if you remember, that's the tool that, e.g., quantifies the
upstream effort of the RT project.

Given a commit hash, we're now able to retrieve several revisions of a
patch. This allows you to navigate through all versions of a patch,
including their discussions. In the long run, patchwork integration is
planned -- will keep you up-to-date.

But therefore we optimally need a full coverage of all lists, and lore
only tracks a small subset of 'most important' lists. This is why we
subscribed to all lists mentioned in the MAINTAINERS file and archive
them in the public inbox format [3]. Currently we track ~190 lists.

I'm maintaining this archive (together with its tooling [4]) for the
moment, but I'd be happy if this could be hosted at some LF server.

  Ralf

[1] https://github.com/lfd/PaStA
[2] https://arxiv.org/pdf/1902.03147.pdf
[3] https://github.com/orgs/linux-mailinglist-archives/
[4] https://github.com/lfd/mail-archiver

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

[James Bottomley]

On Tue, 2019-07-02 at 18:43 -0400, Theodore Ts'o wrote:
> On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> > git is our upstream for version control and our upstream has
> > already
> > had this as a feature since 2014.  Trying to go to upstream  5
> > years
> > later and ask them to change it is likely going to be a singularly
> > unsuccessful exercise, plus even in the unlikely event we can work
> > out
> > how to do it compatibly and without causing confusion and upstream
> > said
> > yes it would take another few years to propagate.
> 
> If we really want to use the Link: header, we should be able to do
> this without requiring any changes to git.
> 
> Step 1)   git config am.messageid true
> Step 2)   Write and install a .git/hooks/applypatch-msg script which
> 	  looks for Message-Id: and transmogrifies that line to a
> 	  Link: trailer, using the lore.kernel.org URL template
> Step 3)   Document this in Documentation/process.  For bonus points
> 	  create a script which automatically sets up the user's git
> 	  configuration by setting up am.messageid config and
> 	  installing the hook file.
> Step 4)   Profit

But we don't need the intermediate stages of that: Thomas already has a
hook that can pick the Message-Id out of the email and transform it
directly to a Link: tag (although I suspect it might be a pre-
applypatch hook).

The wider point was that if git would just capture the message-id then
we could use it and transform it to what we want to see.  The new
information is that git can do this, just as part of the body not the
metadata, which means we'd see it in the commit stream rather than
having to agree on the script and a hook and make everyone use it.

James

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

[Thomas Gleixner]

On Tue, 2 Jul 2019, James Bottomley wrote:

> On Tue, 2019-07-02 at 18:43 -0400, Theodore Ts'o wrote:
> > On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> > > git is our upstream for version control and our upstream has
> > > already
> > > had this as a feature since 2014.  Trying to go to upstream  5
> > > years
> > > later and ask them to change it is likely going to be a singularly
> > > unsuccessful exercise, plus even in the unlikely event we can work
> > > out
> > > how to do it compatibly and without causing confusion and upstream
> > > said
> > > yes it would take another few years to propagate.
> > 
> > If we really want to use the Link: header, we should be able to do
> > this without requiring any changes to git.
> > 
> > Step 1)   git config am.messageid true
> > Step 2)   Write and install a .git/hooks/applypatch-msg script which
> > 	  looks for Message-Id: and transmogrifies that line to a
> > 	  Link: trailer, using the lore.kernel.org URL template
> > Step 3)   Document this in Documentation/process.  For bonus points
> > 	  create a script which automatically sets up the user's git
> > 	  configuration by setting up am.messageid config and
> > 	  installing the hook file.
> > Step 4)   Profit
> 
> But we don't need the intermediate stages of that: Thomas already has a
> hook that can pick the Message-Id out of the email and transform it
> directly to a Link: tag (although I suspect it might be a pre-
> applypatch hook).

My workflow is not git-am based at all. My script converts a mbox to a
quilt series. That also picks up all tags from replies in mbox and adds the
Link from the message id to each patch.

I use that both for review and to polish stuff before I expose it to git
with git quiltimport and push it out.

But yes, I could easily convert that into a 'prepare mbox for git-am'
tool. I'm happy to do that.

But writing a script which converts the Message-ID tag which git can
generate into a 'Link: lore...' format for whatever git hook is appropriate
is not rocket science either.

Both solutions require the maintainer to do something extra. Ted's proposal
is perhaps more conveniant as it is a one time effort to add the script and
enable the am.messageid thing. But then probably most people have scripts
around git-am so adding it there is equally one time :)

Thanks,

	tglx

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

[Kees Cook]

On Tue, Jul 02, 2019 at 06:43:47PM -0400, Theodore Ts'o wrote:
> On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> > git is our upstream for version control and our upstream has already
> > had this as a feature since 2014.  Trying to go to upstream  5 years
> > later and ask them to change it is likely going to be a singularly
> > unsuccessful exercise, plus even in the unlikely event we can work out
> > how to do it compatibly and without causing confusion and upstream said
> > yes it would take another few years to propagate.
> 
> If we really want to use the Link: header, we should be able to do
> this without requiring any changes to git.
> 
> Step 1)   git config am.messageid true

This is a lossy action: we don't know which list the ID came from (e.g.
many things are sent to subsystem lists and not lkml).

> Step 2)   Write and install a .git/hooks/applypatch-msg script which
> 	  looks for Message-Id: and transmogrifies that line to a
> 	  Link: trailer, using the lore.kernel.org URL template

I think the lorifier.py[1] mentioned earlier has 90% of the "step 2"
logic, including caching the lore list mappings. Is there a "git am" hook
we could build on instead? /me looks. Yes; seems to be "applypatch-msg"?
Unclear if the email headers are included...

[1] https://github.com/danrue/lorifier

-- 
Kees Cook

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

[Theodore Ts'o]

On Tue, Jul 02, 2019 at 04:04:31PM -0700, Kees Cook wrote:
> > Step 1)   git config am.messageid true
> 
> This is a lossy action: we don't know which list the ID came from (e.g.
> many things are sent to subsystem lists and not lkml).

Why do we need to care which list the ID came from?  Many messages are
cc'ed to multiple lists that are archived on lore.kernel.org.  And it
doesn't matter:

	lore.kernel.org/r/<message-id>

... will work without needing to know which list it was sent to.

> > Step 2)   Write and install a .git/hooks/applypatch-msg script which
> > 	  looks for Message-Id: and transmogrifies that line to a
> > 	  Link: trailer, using the lore.kernel.org URL template
> 
> I think the lorifier.py[1] mentioned earlier has 90% of the "step 2"
> logic, including caching the lore list mappings. Is there a "git am" hook
> we could build on instead? /me looks. Yes; seems to be "applypatch-msg"?
> Unclear if the email headers are included...

applypatch-msg is the git hoook I had suggested above.

The documentation states:

    This hook is invoked by git-am[1]. It takes a single parameter,
    the name of the file that holds the proposed commit log
    message. Exiting with a non-zero status causes git am to abort
    before applying the patch.

    The hook is allowed to edit the message file in place, and can be
    used to normalize the message into some project standard
    format. It can also be used to refuse the commit after inspecting
    the message file.


That to me says the e-mail headers have already been stripped.
Fortunately, using am.messageid=true should work since that is part of
the proposed commit message.

					- Ted

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

[Kees Cook]

On Tue, Jul 02, 2019 at 07:18:58PM -0400, Theodore Ts'o wrote:
> On Tue, Jul 02, 2019 at 04:04:31PM -0700, Kees Cook wrote:
> > > Step 1)   git config am.messageid true
> > 
> > This is a lossy action: we don't know which list the ID came from (e.g.
> > many things are sent to subsystem lists and not lkml).
> 
> Why do we need to care which list the ID came from?  Many messages are
> cc'ed to multiple lists that are archived on lore.kernel.org.  And it
> doesn't matter:
> 
> 	lore.kernel.org/r/<message-id>
> 
> ... will work without needing to know which list it was sent to.

Ah yeah, good point. I temporarily forgot about /r/ from reading
lorifier.py :)

-- 
Kees Cook

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

[James Bottomley]

On Tue, 2019-07-02 at 19:18 -0400, Theodore Ts'o wrote:
> On Tue, Jul 02, 2019 at 04:04:31PM -0700, Kees Cook wrote:
> > > Step 1)   git config am.messageid true
> > 
> > This is a lossy action: we don't know which list the ID came from
> > (e.g.
> > many things are sent to subsystem lists and not lkml).
> 
> Why do we need to care which list the ID came from?  Many messages
> are
> cc'ed to multiple lists that are archived on lore.kernel.org.  And it
> doesn't matter:
> 
> 	lore.kernel.org/r/<message-id>
> 
> ... will work without needing to know which list it was sent to.

I think the concern is creating a link that doesn't exist because lore
doesn't archive the list.  For instance this produces a 404:

https://lore.kernel.org/r/1561044605.7970.5.camel@HansenPartnership.com

But this works

http://marc.info/?i=1561044605.7970.5.camel@HansenPartnership.com

James

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

[Theodore Ts'o]

On Tue, Jul 02, 2019 at 04:33:16PM -0700, James Bottomley wrote:
> 
> I think the concern is creating a link that doesn't exist because lore
> doesn't archive the list.  For instance this produces a 404:
> 
> https://lore.kernel.org/r/1561044605.7970.5.camel@HansenPartnership.com
> 
> But this works
> 
> http://marc.info/?i=1561044605.7970.5.camel@HansenPartnership.com

Shouldn't we fix this by making sure lore archives the linux-scsi list?  :-)

More seriously, I this is going to be a general problem, since there
may very well be some lists that won't be archived on marc.info.  So
using a bare Message-Id isn't going to solve this problem.  It seems
the best solution will be bringing all of the kernel mailing lists
into lore.kernel.org.

						- Ted

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

[James Bottomley]

On Wed, 2019-07-03 at 00:16 -0400, Theodore Ts'o wrote:
> On Tue, Jul 02, 2019 at 04:33:16PM -0700, James Bottomley wrote:
> > 
> > I think the concern is creating a link that doesn't exist because
> > lore
> > doesn't archive the list.  For instance this produces a 404:
> > 
> > https://lore.kernel.org/r/1561044605.7970.5.camel@HansenPartnership
> > .com
> > 
> > But this works
> > 
> > http://marc.info/?i=1561044605.7970.5.camel@HansenPartnership.com
> 
> Shouldn't we fix this by making sure lore archives the linux-scsi
> list?  :-)

Well, it has been mentioned, yes ...

> More seriously, I this is going to be a general problem, since there
> may very well be some lists that won't be archived on marc.info.  So
> using a bare Message-Id isn't going to solve this problem.  It seems
> the best solution will be bringing all of the kernel mailing lists
> into lore.kernel.org.

My thought was actually a message-id is more descriptive because it can
be fed into any archive (or even google) to find the email.  However,
it's also easy to strip the message-id out of the lore url and do the
same, so my only weak objection is the URL would be expected to be
functional and the chances are there will always be some patch on some
list that isn't in the archive yet.

James

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

[Kees Cook]

On Tue, Jul 02, 2019 at 09:50:58PM -0700, James Bottomley wrote:
> My thought was actually a message-id is more descriptive because it can
> be fed into any archive (or even google) to find the email.  However,
> it's also easy to strip the message-id out of the lore url and do the
> same, so my only weak objection is the URL would be expected to be
> functional and the chances are there will always be some patch on some
> list that isn't in the archive yet.

What I like, though, is that it is a one-time retro-active fix. If we
discover a missing list we can add it, and suddenly all the URLs
referencing message ids from that list start working. :)

-- 
Kees Cook

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

[Kees Cook]

On Tue, Jul 02, 2019 at 07:18:58PM -0400, Theodore Ts'o wrote:
> On Tue, Jul 02, 2019 at 04:04:31PM -0700, Kees Cook wrote:
> > > Step 1)   git config am.messageid true
> > 
> > This is a lossy action: we don't know which list the ID came from (e.g.
> > many things are sent to subsystem lists and not lkml).
> 
> Why do we need to care which list the ID came from?  Many messages are
> cc'ed to multiple lists that are archived on lore.kernel.org.  And it
> doesn't matter:
> 
> 	lore.kernel.org/r/<message-id>
> 
> ... will work without needing to know which list it was sent to.
> 
> > > Step 2)   Write and install a .git/hooks/applypatch-msg script which
> > > 	  looks for Message-Id: and transmogrifies that line to a
> > > 	  Link: trailer, using the lore.kernel.org URL template
> > 
> > I think the lorifier.py[1] mentioned earlier has 90% of the "step 2"
> > logic, including caching the lore list mappings. Is there a "git am" hook
> > we could build on instead? /me looks. Yes; seems to be "applypatch-msg"?
> > Unclear if the email headers are included...
> 
> applypatch-msg is the git hoook I had suggested above.
> 
> The documentation states:
> 
>     This hook is invoked by git-am[1]. It takes a single parameter,
>     the name of the file that holds the proposed commit log
>     message. Exiting with a non-zero status causes git am to abort
>     before applying the patch.
> 
>     The hook is allowed to edit the message file in place, and can be
>     used to normalize the message into some project standard
>     format. It can also be used to refuse the commit after inspecting
>     the message file.
> 
> 
> That to me says the e-mail headers have already been stripped.
> Fortunately, using am.messageid=true should work since that is part of
> the proposed commit message.

This works for me:

$ git config am.messageid true
$ cat >.git/hooks/applypatch-msg <<'EOF'
#!/bin/sh
. git-sh-setup
perl -pi -e 's|^Message-Id:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1"
test -x "$GIT_DIR/hooks/commit-msg" &&
	exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"}
:
EOF
$ chmod a+x .git/hooks/applypatch-msg

-- 
Kees Cook

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

[Greg KH]

On Tue, Jul 02, 2019 at 04:41:35PM -0700, Kees Cook wrote:
> On Tue, Jul 02, 2019 at 07:18:58PM -0400, Theodore Ts'o wrote:
> > On Tue, Jul 02, 2019 at 04:04:31PM -0700, Kees Cook wrote:
> > > > Step 1)   git config am.messageid true
> > > 
> > > This is a lossy action: we don't know which list the ID came from (e.g.
> > > many things are sent to subsystem lists and not lkml).
> > 
> > Why do we need to care which list the ID came from?  Many messages are
> > cc'ed to multiple lists that are archived on lore.kernel.org.  And it
> > doesn't matter:
> > 
> > 	lore.kernel.org/r/<message-id>
> > 
> > ... will work without needing to know which list it was sent to.
> > 
> > > > Step 2)   Write and install a .git/hooks/applypatch-msg script which
> > > > 	  looks for Message-Id: and transmogrifies that line to a
> > > > 	  Link: trailer, using the lore.kernel.org URL template
> > > 
> > > I think the lorifier.py[1] mentioned earlier has 90% of the "step 2"
> > > logic, including caching the lore list mappings. Is there a "git am" hook
> > > we could build on instead? /me looks. Yes; seems to be "applypatch-msg"?
> > > Unclear if the email headers are included...
> > 
> > applypatch-msg is the git hoook I had suggested above.
> > 
> > The documentation states:
> > 
> >     This hook is invoked by git-am[1]. It takes a single parameter,
> >     the name of the file that holds the proposed commit log
> >     message. Exiting with a non-zero status causes git am to abort
> >     before applying the patch.
> > 
> >     The hook is allowed to edit the message file in place, and can be
> >     used to normalize the message into some project standard
> >     format. It can also be used to refuse the commit after inspecting
> >     the message file.
> > 
> > 
> > That to me says the e-mail headers have already been stripped.
> > Fortunately, using am.messageid=true should work since that is part of
> > the proposed commit message.
> 
> This works for me:
> 
> $ git config am.messageid true
> $ cat >.git/hooks/applypatch-msg <<'EOF'
> #!/bin/sh
> . git-sh-setup
> perl -pi -e 's|^Message-Id:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1"
> test -x "$GIT_DIR/hooks/commit-msg" &&
> 	exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"}
> :
> EOF
> $ chmod a+x .git/hooks/applypatch-msg

I just tried this on my tree and it works great!

thanks for this, I'll start using it on my trees and it also forces me
to finally get the linux-usb tree into lore...

thanks,

greg k-h

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

[Laurent Pinchart]

On Tue, Jul 02, 2019 at 06:43:47PM -0400, Theodore Ts'o wrote:
> On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> > git is our upstream for version control and our upstream has already
> > had this as a feature since 2014.  Trying to go to upstream  5 years
> > later and ask them to change it is likely going to be a singularly
> > unsuccessful exercise, plus even in the unlikely event we can work out
> > how to do it compatibly and without causing confusion and upstream said
> > yes it would take another few years to propagate.
> 
> If we really want to use the Link: header, we should be able to do
> this without requiring any changes to git.
> 
> Step 1)   git config am.messageid true
> Step 2)   Write and install a .git/hooks/applypatch-msg script which
> 	  looks for Message-Id: and transmogrifies that line to a
> 	  Link: trailer, using the lore.kernel.org URL template
> Step 3)   Document this in Documentation/process.  For bonus points
> 	  create a script which automatically sets up the user's git
> 	  configuration by setting up am.messageid config and
> 	  installing the hook file.
> Step 4)   Profit

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) ?

-- 
Regards,

Laurent Pinchart

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

[Thomas Gleixner]

On Wed, 3 Jul 2019, Laurent Pinchart wrote:
> On Tue, Jul 02, 2019 at 06:43:47PM -0400, Theodore Ts'o wrote:
> > On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> > > git is our upstream for version control and our upstream has already
> > > had this as a feature since 2014.  Trying to go to upstream  5 years
> > > later and ask them to change it is likely going to be a singularly
> > > unsuccessful exercise, plus even in the unlikely event we can work out
> > > how to do it compatibly and without causing confusion and upstream said
> > > yes it would take another few years to propagate.
> > 
> > If we really want to use the Link: header, we should be able to do
> > this without requiring any changes to git.
> > 
> > Step 1)   git config am.messageid true
> > Step 2)   Write and install a .git/hooks/applypatch-msg script which
> > 	  looks for Message-Id: and transmogrifies that line to a
> > 	  Link: trailer, using the lore.kernel.org URL template
> > Step 3)   Document this in Documentation/process.  For bonus points
> > 	  create a script which automatically sets up the user's git
> > 	  configuration by setting up am.messageid config and
> > 	  installing the hook file.
> > Step 4)   Profit
> 
> 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) ?

Yes.

If you just commit, post and then send a pull request later how are you
dealing with Reviewed-by/Acked-by/Tested-by replies on the list?

Either they do not end up in the changelogs or you have to redo the commits
anyway. So moving to a always redo from mail/patchwork just unifies the
workflow.

I'm doing that always because I'm way too lazy to collect the tags from
replies manually. I just save the whole thread as mbox and let the tools
sort it out.

Thanks,

	tglx

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

[Leon Romanovsky]

On Wed, Jul 03, 2019 at 11:12:11AM +0200, Thomas Gleixner wrote:
> On Wed, 3 Jul 2019, Laurent Pinchart wrote:
> > On Tue, Jul 02, 2019 at 06:43:47PM -0400, Theodore Ts'o wrote:
> > > On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> > > > git is our upstream for version control and our upstream has already
> > > > had this as a feature since 2014.  Trying to go to upstream  5 years
> > > > later and ask them to change it is likely going to be a singularly
> > > > unsuccessful exercise, plus even in the unlikely event we can work out
> > > > how to do it compatibly and without causing confusion and upstream said
> > > > yes it would take another few years to propagate.
> > >
> > > If we really want to use the Link: header, we should be able to do
> > > this without requiring any changes to git.
> > >
> > > Step 1)   git config am.messageid true
> > > Step 2)   Write and install a .git/hooks/applypatch-msg script which
> > > 	  looks for Message-Id: and transmogrifies that line to a
> > > 	  Link: trailer, using the lore.kernel.org URL template
> > > Step 3)   Document this in Documentation/process.  For bonus points
> > > 	  create a script which automatically sets up the user's git
> > > 	  configuration by setting up am.messageid config and
> > > 	  installing the hook file.
> > > Step 4)   Profit
> >
> > 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) ?
>
> Yes.
>
> If you just commit, post and then send a pull request later how are you
> dealing with Reviewed-by/Acked-by/Tested-by replies on the list?
>
> Either they do not end up in the changelogs or you have to redo the commits
> anyway. So moving to a always redo from mail/patchwork just unifies the
> workflow.
>
> I'm doing that always because I'm way too lazy to collect the tags from
> replies manually. I just save the whole thread as mbox and let the tools
> sort it out.

My 2 cents,

I'm doing the same for slightly different reason, I want to be 100% sure
that posted and reviewed patch equal to applied. So when it is applicable,
I post my own patches and apply them from mailing list later on to
shared rdma<->netdev branch.

Thanks

>
> Thanks,
>
> 	tglx
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

[Laurent Pinchart]

Hello,

On Wed, Jul 03, 2019 at 03:39:54PM +0300, Leon Romanovsky wrote:
> On Wed, Jul 03, 2019 at 11:12:11AM +0200, Thomas Gleixner wrote:
> > On Wed, 3 Jul 2019, Laurent Pinchart wrote:
> > > On Tue, Jul 02, 2019 at 06:43:47PM -0400, Theodore Ts'o wrote:
> > > > On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> > > > > git is our upstream for version control and our upstream has already
> > > > > had this as a feature since 2014.  Trying to go to upstream  5 years
> > > > > later and ask them to change it is likely going to be a singularly
> > > > > unsuccessful exercise, plus even in the unlikely event we can work out
> > > > > how to do it compatibly and without causing confusion and upstream said
> > > > > yes it would take another few years to propagate.
> > > >
> > > > If we really want to use the Link: header, we should be able to do
> > > > this without requiring any changes to git.
> > > >
> > > > Step 1)   git config am.messageid true
> > > > Step 2)   Write and install a .git/hooks/applypatch-msg script which
> > > > 	  looks for Message-Id: and transmogrifies that line to a
> > > > 	  Link: trailer, using the lore.kernel.org URL template
> > > > Step 3)   Document this in Documentation/process.  For bonus points
> > > > 	  create a script which automatically sets up the user's git
> > > > 	  configuration by setting up am.messageid config and
> > > > 	  installing the hook file.
> > > > Step 4)   Profit
> > >
> > > 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) ?
> >
> > Yes.
> >
> > If you just commit, post and then send a pull request later how are you
> > dealing with Reviewed-by/Acked-by/Tested-by replies on the list?
> >
> > Either they do not end up in the changelogs or you have to redo the commits
> > anyway. So moving to a always redo from mail/patchwork just unifies the
> > workflow.
> >
> > I'm doing that always because I'm way too lazy to collect the tags from
> > replies manually. I just save the whole thread as mbox and let the tools
> > sort it out.

I usually pick the tags manually. I started doing so because I was too
lazy to apply the patches from an mbox :-) Picking them manually
distributes of time the workload of a final git-am before sending the
pull request, but it has the nice advantage that I can easily see in my
local tree which patches still require review.

> My 2 cents,
> 
> I'm doing the same for slightly different reason, I want to be 100% sure
> that posted and reviewed patch equal to applied. So when it is applicable,
> I post my own patches and apply them from mailing list later on to
> shared rdma<->netdev branch.

I understand both your and Thomas' rationales, and I know that the DRM
subsystem has enforced usage of the Link: tag through the dim tool used
to maintain drm-misc. I initially found it a bit of a burden to have to
go and retrieve patches from my mail client or from patchwork, but I
also understand the upside. Should we make it an official recommendation
recorded in written documentation ?

When time permit I will likely try to see if I can automate retrieval of
a patch series. Ideally I'd like a script that would take a branch,
identifies where to get the patches from, and goes and pick them up
(retaining the history below --- until it's time for the final pull
request). That may not be too difficult to achieve.

-- 
Regards,

Laurent Pinchart

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

[Theodore Ts'o]

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

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

[Jan Kara]

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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

On Wed, Jul 03, 2019 at 04:10:13PM +0200, Jan Kara wrote:

> 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...

The other thing with the link tag is that if we can automate generating
it it doesn't really cost us anything - it's going to be more effort to
decide if it's useful than it is to just add it unconditionally.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Frank Rowand]

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
> 

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

[Linus Walleij]

On Wed, Jul 3, 2019 at 3:51 PM Theodore Ts'o <tytso@mit.edu> wrote:

> 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.

I agree. I recently wanted to look into the development history
of the contiguous memory allocator merged in 2012. This patch set
went through 24 (!) iterations duly summarized in the cover letter:
https://lore.kernel.org/lkml/1333462221-3987-1-git-send-email-m.szyprowski@samsung.com/
it not is on mm/cma.c.

The links to the earlier iterations on gmane are dead.

It is one of the more heroic attempts to fix a very real problem
with memory management in embedded and mobile,
the second part of which is hopefully coming to a resolution
with John Stultz work on the ION destaging (ongoing).

The actual commit in the kernel looks like so:
git log c64be2bb1c6eb43c838b2c6d57b074078be208dd

I would have to dig them all out of lore one by one to get
the picture (and I guess I will). The story of CMA is a really
interesting one, and now it is part of the MM core.
Documentation/cma is pretty empty.

Asking Michal, Marek and Joonsoo who all worked hard on
this to summarize the development and make the design
and evolution of this feature understandable would be a
pretty big development task in itself so I'm not gonna.

But maybe we should just merge a document with lore
pointers to Documentation/cma for this feature, and others
of the same impact?

Yours,
Linus Walleij

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

[Mike Rapoport]

Hi,

On Fri, Jul 05, 2019 at 11:26:22AM +0200, Linus Walleij wrote:
> On Wed, Jul 3, 2019 at 3:51 PM Theodore Ts'o <tytso@mit.edu> wrote:
> 
> > 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.
> 
> I agree. I recently wanted to look into the development history
> of the contiguous memory allocator merged in 2012. This patch set
> went through 24 (!) iterations duly summarized in the cover letter:
> https://lore.kernel.org/lkml/1333462221-3987-1-git-send-email-m.szyprowski@samsung.com/
> it not is on mm/cma.c.
> 
> The links to the earlier iterations on gmane are dead.
> 
> It is one of the more heroic attempts to fix a very real problem
> with memory management in embedded and mobile,
> the second part of which is hopefully coming to a resolution
> with John Stultz work on the ION destaging (ongoing).
> 
> The actual commit in the kernel looks like so:
> git log c64be2bb1c6eb43c838b2c6d57b074078be208dd
> 
> I would have to dig them all out of lore one by one to get
> the picture (and I guess I will). The story of CMA is a really
> interesting one, and now it is part of the MM core.
> Documentation/cma is pretty empty.
> 
> Asking Michal, Marek and Joonsoo who all worked hard on
> this to summarize the development and make the design
> and evolution of this feature understandable would be a
> pretty big development task in itself so I'm not gonna.
> 
> But maybe we should just merge a document with lore
> pointers to Documentation/cma for this feature, and others
> of the same impact?

If you anyway going to dig through it, putting a summary with lore pointers
in Documentation/ would be great.
 
> Yours,
> Linus Walleij
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

-- 
Sincerely yours,
Mike.

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

[Theodore Ts'o]

On Fri, Jul 05, 2019 at 11:26:22AM +0200, Linus Walleij wrote:
> I would have to dig them all out of lore one by one to get
> the picture (and I guess I will). The story of CMA is a really
> interesting one, and now it is part of the MM core.
> Documentation/cma is pretty empty.
> 
> Asking Michal, Marek and Joonsoo who all worked hard on
> this to summarize the development and make the design
> and evolution of this feature understandable would be a
> pretty big development task in itself so I'm not gonna.

I assume you want something more detailed than this article on LWN?

	https://lwn.net/Articles/486301/

I vaguely remember there was a presentation at Plumbers, but of course
that was a long time ago, before we were regularly recording
presentations at LPC.

It may be that best sort of thing will be conference presentations
and/or refereed papers.  For example, there will be a 2019 Usenix ATC
about EROFS.

	https://www.usenix.org/conference/atc19/presentation/gao

Of course, asking developers to write refereed papers for submission
to Usenix, FAST, etc., or even giving a presentation at Plumbers is
also an awful lot to ask.  :-)

					- Ted

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

[Frank Rowand]

On 7/5/19 9:42 PM, Theodore Ts'o wrote:
> On Fri, Jul 05, 2019 at 11:26:22AM +0200, Linus Walleij wrote:
>> I would have to dig them all out of lore one by one to get
>> the picture (and I guess I will). The story of CMA is a really
>> interesting one, and now it is part of the MM core.
>> Documentation/cma is pretty empty.
>>
>> Asking Michal, Marek and Joonsoo who all worked hard on
>> this to summarize the development and make the design
>> and evolution of this feature understandable would be a
>> pretty big development task in itself so I'm not gonna.
> 
> I assume you want something more detailed than this article on LWN?
> 
> 	https://lwn.net/Articles/486301/
> 
> I vaguely remember there was a presentation at Plumbers, but of course
> that was a long time ago, before we were regularly recording
> presentations at LPC.
> 
> It may be that best sort of thing will be conference presentations
> and/or refereed papers.  For example, there will be a 2019 Usenix ATC
> about EROFS.
> 
> 	https://www.usenix.org/conference/atc19/presentation/gao
> 
> Of course, asking developers to write refereed papers for submission
> to Usenix, FAST, etc., or even giving a presentation at Plumbers is
> also an awful lot to ask.  :-)

Then the next step is to have a way to find those papers.

Search engines are sometimes helpful.

For the Embedded Linux Conference (ELC) and Embedded Linux Conference
Europe (ELCE), there is an easy to scan table of presentations and
their slides and videos for each year of the conference.  It is a
two step search, the top level is a link to each year of the
conference:

   https://elinux.org/ELC_Presentations

then following the link from there gets you to the table of
presentations, for example ELCE 2018 is at:

   https://elinux.org/ELC_Europe_2018_Presentations

An example of a more organized list of conference presentations for
one subsystem is a reference to devicetree conference presentations
at:

   https://elinux.org/Device_Tree_presentations_papers_articles

Each presentation is listed twice, once by topic area(s) and once
by date.

-Frank

> 
> 					- Ted
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

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

[James Bottomley]

On Wed, 2019-07-03 at 11:56 +0300, Laurent Pinchart wrote:
> On Tue, Jul 02, 2019 at 06:43:47PM -0400, Theodore Ts'o wrote:
> > On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> > > git is our upstream for version control and our upstream has
> > > already
> > > had this as a feature since 2014.  Trying to go to upstream  5
> > > years
> > > later and ask them to change it is likely going to be a
> > > singularly
> > > unsuccessful exercise, plus even in the unlikely event we can
> > > work out
> > > how to do it compatibly and without causing confusion and
> > > upstream said
> > > yes it would take another few years to propagate.
> > 
> > If we really want to use the Link: header, we should be able to do
> > this without requiring any changes to git.
> > 
> > Step 1)   git config am.messageid true
> > Step 2)   Write and install a .git/hooks/applypatch-msg script
> > which
> > 	  looks for Message-Id: and transmogrifies that line to a
> > 	  Link: trailer, using the lore.kernel.org URL template
> > Step 3)   Document this in Documentation/process.  For bonus points
> > 	  create a script which automatically sets up the user's git
> > 	  configuration by setting up am.messageid config and
> > 	  installing the hook file.
> > Step 4)   Profit
> 
> 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) ?

I always apply from the list.  Apart from the obvious benefit of
getting others to review and not giving the impression of a favourite
path into the tree, I do it because as I construct patches and rework
them I actually build the version information into the change log using
rebase (with a --- separating it from the main commit message).  This
is so I can send the emails directly from my tree without having to add
the version change information but it does mean the only way I lose the
version history from my patches when they go into the tree for real is
by doing an am apply from the list.

James

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

[Geert Uytterhoeven]

On Thu, Jul 4, 2019 at 1:04 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2019-07-03 at 11:56 +0300, Laurent Pinchart wrote:
> > On Tue, Jul 02, 2019 at 06:43:47PM -0400, Theodore Ts'o wrote:
> > > On Tue, Jul 02, 2019 at 03:26:48PM -0700, James Bottomley wrote:
> > > > git is our upstream for version control and our upstream has
> > > > already
> > > > had this as a feature since 2014.  Trying to go to upstream  5
> > > > years
> > > > later and ask them to change it is likely going to be a
> > > > singularly
> > > > unsuccessful exercise, plus even in the unlikely event we can
> > > > work out
> > > > how to do it compatibly and without causing confusion and
> > > > upstream said
> > > > yes it would take another few years to propagate.
> > >
> > > If we really want to use the Link: header, we should be able to do
> > > this without requiring any changes to git.
> > >
> > > Step 1)   git config am.messageid true
> > > Step 2)   Write and install a .git/hooks/applypatch-msg script
> > > which
> > >       looks for Message-Id: and transmogrifies that line to a
> > >       Link: trailer, using the lore.kernel.org URL template
> > > Step 3)   Document this in Documentation/process.  For bonus points
> > >       create a script which automatically sets up the user's git
> > >       configuration by setting up am.messageid config and
> > >       installing the hook file.
> > > Step 4)   Profit
> >
> > 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) ?
>
> I always apply from the list.  Apart from the obvious benefit of
> getting others to review and not giving the impression of a favourite

I cherry-pick them from my development branch, and rebase -i to add
missing Reviewed-by's, and remove cruft below --- (see below).

For other people's patches, I usually don't apply them from patchwork
(perhaps I should start doing that), but use a custom script to extract
a patch or patch series from my Gmail backup, based on the Message-ID
of the patch or cover letter.  So that's a step where I could auto-add
the Link:.

> path into the tree, I do it because as I construct patches and rework
> them I actually build the version information into the change log using
> rebase (with a --- separating it from the main commit message).  This
> is so I can send the emails directly from my tree without having to add

Same here: I keep the change logs in the commits in my development
branch, and rebase -i to update the logs and add Reviewed-by's.
I use the different colored stars in Gmail to mark patches to queue, or
patches that have new tags to apply.

> the version change information but it does mean the only way I lose the
> version history from my patches when they go into the tree for real is
> by doing an am apply from the list.

Once in a while I do want to keep the version history (mainly when
publishing a topic branch containing someone else's work), but I haven't
found a git am option to do that automatically.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Linus Walleij]

On Wed, Jul 3, 2019 at 10:56 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> 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) ?

This is what I do in DRM as this subsystem requires the list ID.

I agree it's a bit impractical.

Yours,
Linus Walleij

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

[Thomas Gleixner]

On Tue, 2 Jul 2019, James Bottomley wrote:
> On Wed, 2019-07-03 at 00:07 +0200, Thomas Gleixner wrote:
> > On Tue, 2 Jul 2019, James Bottomley wrote:
> 
> git is our upstream for version control and our upstream has already
> had this as a feature since 2014.  Trying to go to upstream  5 years
> later and ask them to change it is likely going to be a singularly
> unsuccessful exercise, plus even in the unlikely event we can work out
> how to do it compatibly and without causing confusion and upstream said
> yes it would take another few years to propagate.

The point is that 10+ years ago we had:

 LKML-Reference: <message.id>

That upset Linus and he asked explicitely for a proper link. We changed it
to Link: ....  That's why lkml.kernel.org/r/ exists in the first
place. That happened in 2011 (I'm just too tired to find that old mail
thread now) The author of this Message-ID change was well aware of that in
2014...

So now you want to go back to that old scheme which we replaced 8+ years
ago?

> > We really don't want yet another version of tag for that purpose. The
> > 'Link:' tag is documented and proven to be useful.
> 
> You were the one pushing this, do you really want to hold it up because
> what's available isn't exactly what you want?
> 
> What's wrong with Kees' suggestion that we add a new config option to
> determine how we display the tag?  The information is basically there
> so a Message-Id: tag can be converted to any type of Link: tag you
> like.

And that new config option just works and does not require any changes to
git? If so, problem solved. If not, you still have to talk to the git
folks.
 
> I'm going to be a lot more successful going to the git upstream and
> saying we've already been using a Link tag for a while, so we'd like
> your message-id to appear as a Link: for compatibility than I am going
> to be to try to get them to add a Link: tag ...

I did not say that we have to make them add a shiny new Link tag.

Of course if there is already a Message-ID magic, then building upon it
by making it customizable is the obvious solution.

Thanks,

	tglx

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

[James Bottomley]

On Wed, 2019-07-03 at 00:48 +0200, Thomas Gleixner wrote:
> On Tue, 2 Jul 2019, James Bottomley wrote:
> > On Wed, 2019-07-03 at 00:07 +0200, Thomas Gleixner wrote:
> > > On Tue, 2 Jul 2019, James Bottomley wrote:
> > 
> > git is our upstream for version control and our upstream has
> > already had this as a feature since 2014.  Trying to go to
> > upstream  5 years later and ask them to change it is likely going
> > to be a singularly unsuccessful exercise, plus even in the unlikely
> > event we can work out how to do it compatibly and without causing
> > confusion and upstream said yes it would take another few years to
> > propagate.
> 
> The point is that 10+ years ago we had:
> 
>  LKML-Reference: <message.id>
> 
> That upset Linus and he asked explicitely for a proper link. We
> changed it to Link: ....  That's why lkml.kernel.org/r/ exists in the
> first place. That happened in 2011 (I'm just too tired to find that
> old mail thread now) The author of this Message-ID change was well
> aware of that in 2014...
> 
> So now you want to go back to that old scheme which we replaced 8+
> years ago?

At the moment I'm just pointing out that git has has the message-id
capture feature for too long to try to make them add it in a different
way, so if we want to use what git itself does rather than script our
own solution we're a bit stuck if we don't like the tag.

> > > We really don't want yet another version of tag for that purpose.
> > > The 'Link:' tag is documented and proven to be useful.
> > 
> > You were the one pushing this, do you really want to hold it up
> > because what's available isn't exactly what you want?
> > 
> > What's wrong with Kees' suggestion that we add a new config option
> > to determine how we display the tag?  The information is basically
> > there so a Message-Id: tag can be converted to any type of Link:
> > tag you like.
> 
> And that new config option just works and does not require any
> changes to git? If so, problem solved. If not, you still have to talk
> to the git folks.

No, this new config option would need to be accepted upstream first. 
But it can be scripted now so you can have a git log command that
transforms the Message-Id: to a Link: in whatever format you want.

> > I'm going to be a lot more successful going to the git upstream and
> > saying we've already been using a Link tag for a while, so we'd
> > like your message-id to appear as a Link: for compatibility than I
> > am going to be to try to get them to add a Link: tag ...
> 
> I did not say that we have to make them add a shiny new Link tag.
> 
> Of course if there is already a Message-ID magic, then building upon
> it by making it customizable is the obvious solution.

An option that transforms how it goes into the commit instead of one
that transforms how it appears in git-log?  If they'd accept a
transform on log option, I'm sure they'd accept a transform on commit
one.

James

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

[Shuah Khan]

On 7/2/19 9:51 AM, James Bottomley wrote:
> On Tue, 2019-07-02 at 09:39 -0600, Shuah Khan wrote:
>> On 7/2/19 9:18 AM, James Bottomley wrote:
>>> On Tue, 2019-07-02 at 08:10 -0700, James Bottomley wrote:
>>>> On Tue, 2019-07-02 at 16:49 +0200, Thomas Gleixner wrote:
>>>
>>> [...]
>>>>> People who use the link tag today have their homebrewn scripts
>>>>> to add them automatically and it shouldn't be rocket science to
>>>>> add that to git, patchwork whatever.
>>>>
>>>> So if we find a way of automating this globally, I'm completely
>>>> happy. However, I would also note that whatever script does this
>>>> could likely also be run by you after the fact to generate the
>>>> back link, so foolproof automation also lessens the need to make
>>>> this a mandatory commit tag.
>>>
>>> Just on this one, it looks like getting git to archive the msgid of
>>> the patch commit would assist any script that goes off and tries to
>>> find patch series and its precursors in the archives, so perhaps
>>> adding that would be the actionable change in all of this?
>>>
>>
>> Looks like two things are emerging from my original thread that aimed
>> to get clarification on including "Patch revision information" in
>> commit logs.
>>
>> 1. Judiciously including information from the "Patch revision info."
>>      in the commit log could be valuable. Don't just bloat the commit
>>      log with trivial change history. This is part of patch review
>>      process and will not require any scripting. Maybe an update to
>>      the patch submit guidelines documents.
> 
> Agree, as long as it's what Thomas and I have been discussing: namely
> keeping the version information below the --- permanent history cutoff,
> so it's visible to reviewers but won't become part of the permanent
> patch history when the patch is committed to git.
> 

Yes that is what I have in mind. Below the -- permanent history cutoff
to help reviewers.

> I think the bit we're still arguing about is the link to prior series
> as part of this below the line version history.  I agree it's useful,
> but I also think it would be a burden to enforce for every patch
> series.
> 
>> 2. Archiving msgid of the patch commit for reference. This one would
>>      require some scripting to make it easier for maintainers.
> 
> Yes, I think we all agree on this.  The real question is how.  If we
> make git do it, I think trivially Message-Id: can become part of the
> optional metadata.  Or we could all use commit hooks that add a link
> tag.  Personally I prefer the former because it would be universally
> done with no effort but I recognise it would take time to get the
> ecosystem change to propagate.
> 

I think having git do it is better way to go. It becomes part of git
work-flow. There is no need to educate developers yet another script
and process.

thanks,
-- Shuah

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

[Thomas Gleixner]

On Tue, 2 Jul 2019, James Bottomley wrote:
> On Tue, 2019-07-02 at 16:49 +0200, Thomas Gleixner wrote:
> > On Tue, 2 Jul 2019, James Bottomley wrote:
> > > On Mon, 2019-07-01 at 19:54 +0200, Thomas Gleixner wrote:
> > > > The link to V2 is in both cases in the cover letter. That's
> > > > sufficient. Yes, it might not be necessary, but I just recently
> > > > ended up wasting an hour finding an earlier version because the
> > > > cover letter subject changed slightly. I surely have better
> > > > things to do.
> > > 
> > > I'm not arguing against changelogs in the patches themselves as
> > > long as they're below the commit message --- cutoff.  In fact I
> > > think that's best practice for reviewers.  I'm just arguing making
> > > a link tag mandatory would impose an enforcement burden on a lot of
> > > subsystems which would provide no benefit to them), so I don't mind
> > > it's being optional but it shouldn't be mandatory.
> > 
> > What's the burden exactly?
> 
> Not everyone knows what a message ID is or how to find it, so we'd have
> to explain why the patch was rejected (or simply have the maintainer
> add it at commit time, which currently involves some effort).  Quite a
> few of the list archives mangle it so someone would have to notice this
> or unmangle it.
> 
> > You mean that people would have to add them manually?
> 
> Most email tools don't show you the msgid, so if you're simply doing
> driveby commits now we have to explain to you how to find it ...
> remember linux-scsi isn't currently on lore so we can't just say "use
> the lore archive".

The submitter has not to do anything for a drive by patch. The maintainer
who grabs it from the list adds the tags (with tools).

> There's also a knock on: for this to be useful, the commit series needs
> to be threaded.  I've actually no objection to making this one
> mandatory I'm just noting it's another precursor we need to think
> about.
> 
> > People who use the link tag today have their homebrewn scripts to add
> > them automatically and it shouldn't be rocket science to add that to
> > git, patchwork whatever.
> 
> So if we find a way of automating this globally, I'm completely happy. 
> However, I would also note that whatever script does this could likely
> also be run by you after the fact to generate the back link, so
> foolproof automation also lessens the need to make this a mandatory
> commit tag.

That's what I'm doing today. My mbox to quilt converter inserts the Link
tag.

So let's take a step back.

1) Link tag in the commit itself.

   That's added by the person who applies a patch from mail,
   i.e. maintainer.

   That needs tooling support in git, patchwork etc. which should be a
   solvable problem.

2) Link to a previous version of patch series in the cover letter

   Lot of people provide already links in their cover letter. Many of them
   unfortunately use lkml.org which is a pain, but it's better than
   nothing.

   Ideally we can bring people to use the MSG id based links because they
   do not depend on any particular archive.

   That needs a bit more education. Proper documentation should solve that
   over time. If people use lkml.org for the link until they figure out
   what a message id is, fine.

Thanks,

	tglx

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

[James Bottomley]

On Tue, 2019-07-02 at 17:30 +0200, Thomas Gleixner wrote:
> On Tue, 2 Jul 2019, James Bottomley wrote:
> > On Tue, 2019-07-02 at 16:49 +0200, Thomas Gleixner wrote:
> > > On Tue, 2 Jul 2019, James Bottomley wrote:
> > > > On Mon, 2019-07-01 at 19:54 +0200, Thomas Gleixner wrote:
> > > > > The link to V2 is in both cases in the cover letter. That's
> > > > > sufficient. Yes, it might not be necessary, but I just
> > > > > recently ended up wasting an hour finding an earlier version
> > > > > because the cover letter subject changed slightly. I surely
> > > > > have better things to do.
> > > > 
> > > > I'm not arguing against changelogs in the patches themselves as
> > > > long as they're below the commit message --- cutoff.  In fact I
> > > > think that's best practice for reviewers.  I'm just arguing
> > > > making a link tag mandatory would impose an enforcement burden
> > > > on a lot of subsystems which would provide no benefit to them),
> > > > so I don't mind it's being optional but it shouldn't be
> > > > mandatory.
> > > 
> > > What's the burden exactly?
> > 
> > Not everyone knows what a message ID is or how to find it, so we'd
> > have to explain why the patch was rejected (or simply have the
> > maintainer add it at commit time, which currently involves some
> > effort).  Quite a few of the list archives mangle it so someone
> > would have to notice this or unmangle it.
> > 
> > > You mean that people would have to add them manually?
> > 
> > Most email tools don't show you the msgid, so if you're simply
> > doing driveby commits now we have to explain to you how to find it
> > ... remember linux-scsi isn't currently on lore so we can't just
> > say "use the lore archive".
> 
> The submitter has not to do anything for a drive by patch. The
> maintainer who grabs it from the list adds the tags (with tools).

They do for a link to a previous patch set.

> > There's also a knock on: for this to be useful, the commit series
> > needs to be threaded.  I've actually no objection to making this
> > one mandatory I'm just noting it's another precursor we need to
> > think about.
> > 
> > > People who use the link tag today have their homebrewn scripts to
> > > add them automatically and it shouldn't be rocket science to add
> > > that to git, patchwork whatever.
> > 
> > So if we find a way of automating this globally, I'm completely
> > happy. However, I would also note that whatever script does this
> > could likely also be run by you after the fact to generate the back
> > link, so foolproof automation also lessens the need to make this a
> > mandatory commit tag.
> 
> That's what I'm doing today. My mbox to quilt converter inserts the
> Link tag.
> 
> So let's take a step back.
> 
> 1) Link tag in the commit itself.
> 
>    That's added by the person who applies a patch from mail,
>    i.e. maintainer.
> 
>    That needs tooling support in git, patchwork etc. which should be
> a
>    solvable problem.

Agree, can be done completely by tooling with no manual effort.  I also
think we should engage the git people so this simply becomes automatic
metadata for all git-am processed commits.

> 2) Link to a previous version of patch series in the cover letter
> 
>    Lot of people provide already links in their cover letter. Many of
> them
>    unfortunately use lkml.org which is a pain, but it's better than
>    nothing.
> 
>    Ideally we can bring people to use the MSG id based links because
> they
>    do not depend on any particular archive.
> 
>    That needs a bit more education. Proper documentation should solve
> that
>    over time. If people use lkml.org for the link until they figure
> out
>    what a message id is, fine.

This is the bit that I think is the problem.  However, if it's optional
but recommended I'm happy ... drive by committers won't do it, we don't
have to add it for them and likely if they were forced to do a V2 there
wasn't much illuminating content in V1 because it's probably process or
other trivial changes.

James

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

[Thomas Gleixner]

On Tue, 2 Jul 2019, James Bottomley wrote:
> On Tue, 2019-07-02 at 17:30 +0200, Thomas Gleixner wrote:
> > 2) Link to a previous version of patch series in the cover letter
> > 
> >    Lot of people provide already links in their cover letter. Many of
> > them
> >    unfortunately use lkml.org which is a pain, but it's better than
> >    nothing.
> > 
> >    Ideally we can bring people to use the MSG id based links because
> > they
> >    do not depend on any particular archive.
> > 
> >    That needs a bit more education. Proper documentation should solve
> > that
> >    over time. If people use lkml.org for the link until they figure
> > out
> >    what a message id is, fine.
> 
> This is the bit that I think is the problem.  However, if it's optional
> but recommended I'm happy ... drive by committers won't do it, we don't
> have to add it for them and likely if they were forced to do a V2 there
> wasn't much illuminating content in V1 because it's probably process or
> other trivial changes.

Yes. I'm not worried about those. It mostly matters for larger patch series.

Thanks,

	tglx

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

[Jiri Kosina]

On Tue, 2 Jul 2019, James Bottomley wrote:

> remember linux-scsi isn't currently on lore so we can't just say "use
> the lore archive".

FWIW, as I've just recently learned, adding ML to lore is trivial. And if 
you have archive in some reasonable format, they can populate the archive 
with it as well.

https://korg.wiki.kernel.org/userdoc/lore#collecting_archive_donations

-- 
Jiri Kosina
SUSE Labs