* [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? @ 2019-06-28 20:11 Shuah Khan 2019-06-28 20:51 ` Luck, Tony ` (2 more replies) 0 siblings, 3 replies; 106+ messages in thread From: Shuah Khan @ 2019-06-28 20:11 UTC (permalink / raw) To: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-28 20:11 [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? Shuah Khan @ 2019-06-28 20:51 ` Luck, Tony 2019-06-28 21:05 ` Kees Cook ` (4 more replies) 2019-06-28 21:07 ` James Bottomley 2019-07-01 15:06 ` David Howells 2 siblings, 5 replies; 106+ messages in thread From: Luck, Tony @ 2019-06-28 20:51 UTC (permalink / raw) To: Shuah Khan; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-28 20:51 ` Luck, Tony @ 2019-06-28 21:05 ` Kees Cook 2019-06-28 21:07 ` Shuah Khan ` (3 subsequent siblings) 4 siblings, 0 replies; 106+ messages in thread From: Kees Cook @ 2019-06-28 21:05 UTC (permalink / raw) To: Luck, Tony; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-28 20:51 ` Luck, Tony 2019-06-28 21:05 ` Kees Cook @ 2019-06-28 21:07 ` Shuah Khan 2019-06-28 21:13 ` James Bottomley 2019-06-28 21:07 ` Wolfram Sang ` (2 subsequent siblings) 4 siblings, 1 reply; 106+ messages in thread From: Shuah Khan @ 2019-06-28 21:07 UTC (permalink / raw) To: Luck, Tony; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-28 21:07 ` Shuah Khan @ 2019-06-28 21:13 ` James Bottomley 2019-06-28 21:42 ` Shuah Khan 0 siblings, 1 reply; 106+ messages in thread From: James Bottomley @ 2019-06-28 21:13 UTC (permalink / raw) To: Shuah Khan, Luck, Tony; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-28 21:13 ` James Bottomley @ 2019-06-28 21:42 ` Shuah Khan 0 siblings, 0 replies; 106+ messages in thread From: Shuah Khan @ 2019-06-28 21:42 UTC (permalink / raw) To: James Bottomley, Luck, Tony; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-28 20:51 ` Luck, Tony 2019-06-28 21:05 ` Kees Cook 2019-06-28 21:07 ` Shuah Khan @ 2019-06-28 21:07 ` Wolfram Sang 2019-06-29 6:19 ` Thomas Gleixner 2019-06-29 6:57 ` Takashi Iwai 4 siblings, 0 replies; 106+ messages in thread From: Wolfram Sang @ 2019-06-28 21:07 UTC (permalink / raw) To: Luck, Tony; +Cc: ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-28 20:51 ` Luck, Tony ` (2 preceding siblings ...) 2019-06-28 21:07 ` Wolfram Sang @ 2019-06-29 6:19 ` Thomas Gleixner 2019-06-29 9:10 ` Christian Brauner ` (2 more replies) 2019-06-29 6:57 ` Takashi Iwai 4 siblings, 3 replies; 106+ messages in thread From: Thomas Gleixner @ 2019-06-29 6:19 UTC (permalink / raw) To: Luck, Tony; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 6:19 ` Thomas Gleixner @ 2019-06-29 9:10 ` Christian Brauner 2019-06-29 13:43 ` Andrea Parri 2019-07-02 4:40 ` Leon Romanovsky 2 siblings, 0 replies; 106+ messages in thread From: Christian Brauner @ 2019-06-29 9:10 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 6:19 ` Thomas Gleixner 2019-06-29 9:10 ` Christian Brauner @ 2019-06-29 13:43 ` Andrea Parri 2019-06-29 15:16 ` Thomas Gleixner 2019-07-02 4:40 ` Leon Romanovsky 2 siblings, 1 reply; 106+ messages in thread From: Andrea Parri @ 2019-06-29 13:43 UTC (permalink / raw) To: Thomas Gleixner; +Cc: Peter Zijlstra, ksummit-discuss > 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 13:43 ` Andrea Parri @ 2019-06-29 15:16 ` Thomas Gleixner 2019-06-30 16:31 ` Konstantin Ryabitsev 0 siblings, 1 reply; 106+ messages in thread From: Thomas Gleixner @ 2019-06-29 15:16 UTC (permalink / raw) To: Andrea Parri; +Cc: Peter Zijlstra, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 15:16 ` Thomas Gleixner @ 2019-06-30 16:31 ` Konstantin Ryabitsev 2019-07-01 7:20 ` Peter Zijlstra 2019-07-01 9:48 ` Andrea Parri 0 siblings, 2 replies; 106+ messages in thread From: Konstantin Ryabitsev @ 2019-06-30 16:31 UTC (permalink / raw) To: Thomas Gleixner; +Cc: Peter Zijlstra, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-30 16:31 ` Konstantin Ryabitsev @ 2019-07-01 7:20 ` Peter Zijlstra 2019-07-01 7:49 ` Thomas Gleixner 2019-07-01 9:48 ` Andrea Parri 1 sibling, 1 reply; 106+ messages in thread From: Peter Zijlstra @ 2019-07-01 7:20 UTC (permalink / raw) To: Thomas Gleixner, Andrea Parri, ksummit-discuss 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/"). ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 7:20 ` Peter Zijlstra @ 2019-07-01 7:49 ` Thomas Gleixner 2019-07-01 7:53 ` Takashi Iwai 2019-07-01 17:27 ` Steven Rostedt 0 siblings, 2 replies; 106+ messages in thread From: Thomas Gleixner @ 2019-07-01 7:49 UTC (permalink / raw) To: Peter Zijlstra; +Cc: ksummit-discuss 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 .... ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 7:49 ` Thomas Gleixner @ 2019-07-01 7:53 ` Takashi Iwai 2019-07-17 9:23 ` Dan Carpenter 2019-07-01 17:27 ` Steven Rostedt 1 sibling, 1 reply; 106+ messages in thread From: Takashi Iwai @ 2019-07-01 7:53 UTC (permalink / raw) To: Thomas Gleixner; +Cc: Peter Zijlstra, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 7:53 ` Takashi Iwai @ 2019-07-17 9:23 ` Dan Carpenter 2019-07-17 9:27 ` Dan Carpenter 2019-07-17 9:28 ` Greg KH 0 siblings, 2 replies; 106+ messages in thread From: Dan Carpenter @ 2019-07-17 9:23 UTC (permalink / raw) To: Takashi Iwai; +Cc: Peter Zijlstra, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-17 9:23 ` Dan Carpenter @ 2019-07-17 9:27 ` Dan Carpenter 2019-07-17 9:28 ` Greg KH 1 sibling, 0 replies; 106+ messages in thread From: Dan Carpenter @ 2019-07-17 9:27 UTC (permalink / raw) To: Takashi Iwai; +Cc: Peter Zijlstra, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-17 9:23 ` Dan Carpenter 2019-07-17 9:27 ` Dan Carpenter @ 2019-07-17 9:28 ` Greg KH 2019-07-17 16:09 ` Linus Walleij 1 sibling, 1 reply; 106+ messages in thread From: Greg KH @ 2019-07-17 9:28 UTC (permalink / raw) To: Dan Carpenter; +Cc: Peter Zijlstra, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-17 9:28 ` Greg KH @ 2019-07-17 16:09 ` Linus Walleij 2019-07-17 20:44 ` Greg KH ` (2 more replies) 0 siblings, 3 replies; 106+ messages in thread From: Linus Walleij @ 2019-07-17 16:09 UTC (permalink / raw) To: Greg KH, Kees Cook; +Cc: Peter Zijlstra, ksummit, Dan Carpenter 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-17 16:09 ` Linus Walleij @ 2019-07-17 20:44 ` Greg KH 2019-07-18 9:09 ` Linus Walleij 2019-07-22 17:02 ` Kees Cook 2 siblings, 0 replies; 106+ messages in thread From: Greg KH @ 2019-07-17 20:44 UTC (permalink / raw) To: Linus Walleij; +Cc: Peter Zijlstra, ksummit, Dan Carpenter 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-17 16:09 ` Linus Walleij 2019-07-17 20:44 ` Greg KH @ 2019-07-18 9:09 ` Linus Walleij 2019-07-22 17:02 ` Kees Cook 2 siblings, 0 replies; 106+ messages in thread From: Linus Walleij @ 2019-07-18 9:09 UTC (permalink / raw) To: Greg KH, Kees Cook, Bjorn Helgaas; +Cc: Peter Zijlstra, ksummit, Dan Carpenter 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-17 16:09 ` Linus Walleij 2019-07-17 20:44 ` Greg KH 2019-07-18 9:09 ` Linus Walleij @ 2019-07-22 17:02 ` Kees Cook 2019-07-22 17:12 ` Joe Perches 2 siblings, 1 reply; 106+ messages in thread From: Kees Cook @ 2019-07-22 17:02 UTC (permalink / raw) To: Linus Walleij; +Cc: Peter Zijlstra, ksummit, Dan Carpenter 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-22 17:02 ` Kees Cook @ 2019-07-22 17:12 ` Joe Perches 0 siblings, 0 replies; 106+ messages in thread From: Joe Perches @ 2019-07-22 17:12 UTC (permalink / raw) To: Kees Cook, Linus Walleij; +Cc: Peter Zijlstra, Dan Carpenter, ksummit 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 7:49 ` Thomas Gleixner 2019-07-01 7:53 ` Takashi Iwai @ 2019-07-01 17:27 ` Steven Rostedt 2019-07-01 17:55 ` Thomas Gleixner 1 sibling, 1 reply; 106+ messages in thread From: Steven Rostedt @ 2019-07-01 17:27 UTC (permalink / raw) To: Thomas Gleixner; +Cc: Peter Zijlstra, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 17:27 ` Steven Rostedt @ 2019-07-01 17:55 ` Thomas Gleixner 0 siblings, 0 replies; 106+ messages in thread From: Thomas Gleixner @ 2019-07-01 17:55 UTC (permalink / raw) To: Steven Rostedt; +Cc: Peter Zijlstra, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-30 16:31 ` Konstantin Ryabitsev 2019-07-01 7:20 ` Peter Zijlstra @ 2019-07-01 9:48 ` Andrea Parri 2019-07-01 9:51 ` Andrea Parri 1 sibling, 1 reply; 106+ messages in thread From: Andrea Parri @ 2019-07-01 9:48 UTC (permalink / raw) To: Thomas Gleixner, Peter Zijlstra, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 9:48 ` Andrea Parri @ 2019-07-01 9:51 ` Andrea Parri 0 siblings, 0 replies; 106+ messages in thread From: Andrea Parri @ 2019-07-01 9:51 UTC (permalink / raw) To: Thomas Gleixner, Peter Zijlstra, ksummit-discuss, Konstantin Ryabitsev +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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 6:19 ` Thomas Gleixner 2019-06-29 9:10 ` Christian Brauner 2019-06-29 13:43 ` Andrea Parri @ 2019-07-02 4:40 ` Leon Romanovsky 2019-07-02 7:27 ` Geert Uytterhoeven 2 siblings, 1 reply; 106+ messages in thread From: Leon Romanovsky @ 2019-07-02 4:40 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 4:40 ` Leon Romanovsky @ 2019-07-02 7:27 ` Geert Uytterhoeven 2019-07-02 9:48 ` Leon Romanovsky 0 siblings, 1 reply; 106+ messages in thread From: Geert Uytterhoeven @ 2019-07-02 7:27 UTC (permalink / raw) To: Leon Romanovsky; +Cc: ksummit 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 7:27 ` Geert Uytterhoeven @ 2019-07-02 9:48 ` Leon Romanovsky 0 siblings, 0 replies; 106+ messages in thread From: Leon Romanovsky @ 2019-07-02 9:48 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: ksummit 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-28 20:51 ` Luck, Tony ` (3 preceding siblings ...) 2019-06-29 6:19 ` Thomas Gleixner @ 2019-06-29 6:57 ` Takashi Iwai 2019-06-29 7:09 ` Thomas Gleixner 4 siblings, 1 reply; 106+ messages in thread From: Takashi Iwai @ 2019-06-29 6:57 UTC (permalink / raw) To: Luck, Tony; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 6:57 ` Takashi Iwai @ 2019-06-29 7:09 ` Thomas Gleixner 2019-06-29 7:18 ` Takashi Iwai ` (2 more replies) 0 siblings, 3 replies; 106+ messages in thread From: Thomas Gleixner @ 2019-06-29 7:09 UTC (permalink / raw) To: Takashi Iwai; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 7:09 ` Thomas Gleixner @ 2019-06-29 7:18 ` Takashi Iwai 2019-06-29 11:20 ` Mark Brown 2019-07-01 9:05 ` Jiri Kosina 2019-07-04 12:15 ` Michael Ellerman 2 siblings, 1 reply; 106+ messages in thread From: Takashi Iwai @ 2019-06-29 7:18 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 7:18 ` Takashi Iwai @ 2019-06-29 11:20 ` Mark Brown 2019-06-30 16:01 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 106+ messages in thread From: Mark Brown @ 2019-06-29 11:20 UTC (permalink / raw) To: Takashi Iwai; +Cc: ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 11:20 ` Mark Brown @ 2019-06-30 16:01 ` Mauro Carvalho Chehab 2019-07-01 1:35 ` Andrew Donnellan 0 siblings, 1 reply; 106+ messages in thread From: Mauro Carvalho Chehab @ 2019-06-30 16:01 UTC (permalink / raw) To: Mark Brown; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-30 16:01 ` Mauro Carvalho Chehab @ 2019-07-01 1:35 ` Andrew Donnellan 2019-07-01 11:10 ` Mark Brown 2019-08-08 5:24 ` Andrew Donnellan 0 siblings, 2 replies; 106+ messages in thread From: Andrew Donnellan @ 2019-07-01 1:35 UTC (permalink / raw) To: Mauro Carvalho Chehab, Mark Brown Cc: 'patchwork@lists.ozlabs.org', ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 1:35 ` Andrew Donnellan @ 2019-07-01 11:10 ` Mark Brown 2019-08-08 5:24 ` Andrew Donnellan 1 sibling, 0 replies; 106+ messages in thread From: Mark Brown @ 2019-07-01 11:10 UTC (permalink / raw) To: Andrew Donnellan Cc: Mauro Carvalho Chehab, 'patchwork@lists.ozlabs.org', ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 1:35 ` Andrew Donnellan 2019-07-01 11:10 ` Mark Brown @ 2019-08-08 5:24 ` Andrew Donnellan 1 sibling, 0 replies; 106+ messages in thread From: Andrew Donnellan @ 2019-08-08 5:24 UTC (permalink / raw) To: Mauro Carvalho Chehab, Mark Brown Cc: 'patchwork@lists.ozlabs.org', ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 7:09 ` Thomas Gleixner 2019-06-29 7:18 ` Takashi Iwai @ 2019-07-01 9:05 ` Jiri Kosina 2019-07-01 9:15 ` Sergey Senozhatsky 2019-07-04 12:15 ` Michael Ellerman 2 siblings, 1 reply; 106+ messages in thread From: Jiri Kosina @ 2019-07-01 9:05 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 9:05 ` Jiri Kosina @ 2019-07-01 9:15 ` Sergey Senozhatsky 0 siblings, 0 replies; 106+ messages in thread From: Sergey Senozhatsky @ 2019-07-01 9:15 UTC (permalink / raw) To: Jiri Kosina; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-29 7:09 ` Thomas Gleixner 2019-06-29 7:18 ` Takashi Iwai 2019-07-01 9:05 ` Jiri Kosina @ 2019-07-04 12:15 ` Michael Ellerman 2019-07-04 13:24 ` Geert Uytterhoeven 2019-07-04 14:22 ` James Bottomley 2 siblings, 2 replies; 106+ messages in thread From: Michael Ellerman @ 2019-07-04 12:15 UTC (permalink / raw) To: Thomas Gleixner, Takashi Iwai; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-04 12:15 ` Michael Ellerman @ 2019-07-04 13:24 ` Geert Uytterhoeven 2019-07-04 14:16 ` Thomas Gleixner 2019-07-04 14:22 ` James Bottomley 1 sibling, 1 reply; 106+ messages in thread From: Geert Uytterhoeven @ 2019-07-04 13:24 UTC (permalink / raw) To: Michael Ellerman; +Cc: ksummit 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-04 13:24 ` Geert Uytterhoeven @ 2019-07-04 14:16 ` Thomas Gleixner 2019-07-05 3:37 ` Michael Ellerman 0 siblings, 1 reply; 106+ messages in thread From: Thomas Gleixner @ 2019-07-04 14:16 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: ksummit 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 :) ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-04 14:16 ` Thomas Gleixner @ 2019-07-05 3:37 ` Michael Ellerman 2019-07-05 4:10 ` Michael Ellerman 0 siblings, 1 reply; 106+ messages in thread From: Michael Ellerman @ 2019-07-05 3:37 UTC (permalink / raw) To: Thomas Gleixner, Geert Uytterhoeven; +Cc: ksummit 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-05 3:37 ` Michael Ellerman @ 2019-07-05 4:10 ` Michael Ellerman 2019-07-05 6:28 ` Thomas Gleixner 0 siblings, 1 reply; 106+ messages in thread From: Michael Ellerman @ 2019-07-05 4:10 UTC (permalink / raw) To: Thomas Gleixner, Geert Uytterhoeven; +Cc: ksummit 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-05 4:10 ` Michael Ellerman @ 2019-07-05 6:28 ` Thomas Gleixner 2019-07-05 8:24 ` Geert Uytterhoeven 0 siblings, 1 reply; 106+ messages in thread From: Thomas Gleixner @ 2019-07-05 6:28 UTC (permalink / raw) To: Michael Ellerman; +Cc: ksummit 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-05 6:28 ` Thomas Gleixner @ 2019-07-05 8:24 ` Geert Uytterhoeven 0 siblings, 0 replies; 106+ messages in thread From: Geert Uytterhoeven @ 2019-07-05 8:24 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-04 12:15 ` Michael Ellerman 2019-07-04 13:24 ` Geert Uytterhoeven @ 2019-07-04 14:22 ` James Bottomley 2019-07-05 3:24 ` Michael Ellerman ` (2 more replies) 1 sibling, 3 replies; 106+ messages in thread From: James Bottomley @ 2019-07-04 14:22 UTC (permalink / raw) To: Michael Ellerman, Thomas Gleixner, Takashi Iwai; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-04 14:22 ` James Bottomley @ 2019-07-05 3:24 ` Michael Ellerman 2019-07-06 14:02 ` Alexandre Belloni 2019-07-05 3:40 ` Michael Ellerman 2019-07-05 8:40 ` Geert Uytterhoeven 2 siblings, 1 reply; 106+ messages in thread From: Michael Ellerman @ 2019-07-05 3:24 UTC (permalink / raw) To: James Bottomley, Thomas Gleixner, Takashi Iwai, corbet; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-05 3:24 ` Michael Ellerman @ 2019-07-06 14:02 ` Alexandre Belloni 2019-07-06 14:57 ` James Bottomley 0 siblings, 1 reply; 106+ messages in thread From: Alexandre Belloni @ 2019-07-06 14:02 UTC (permalink / raw) To: Michael Ellerman; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-06 14:02 ` Alexandre Belloni @ 2019-07-06 14:57 ` James Bottomley 0 siblings, 0 replies; 106+ messages in thread From: James Bottomley @ 2019-07-06 14:57 UTC (permalink / raw) To: Alexandre Belloni, Michael Ellerman; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-04 14:22 ` James Bottomley 2019-07-05 3:24 ` Michael Ellerman @ 2019-07-05 3:40 ` Michael Ellerman 2019-07-05 8:40 ` Geert Uytterhoeven 2 siblings, 0 replies; 106+ messages in thread From: Michael Ellerman @ 2019-07-05 3:40 UTC (permalink / raw) To: James Bottomley, Thomas Gleixner, Takashi Iwai; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-04 14:22 ` James Bottomley 2019-07-05 3:24 ` Michael Ellerman 2019-07-05 3:40 ` Michael Ellerman @ 2019-07-05 8:40 ` Geert Uytterhoeven 2 siblings, 0 replies; 106+ messages in thread From: Geert Uytterhoeven @ 2019-07-05 8:40 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-28 20:11 [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? Shuah Khan 2019-06-28 20:51 ` Luck, Tony @ 2019-06-28 21:07 ` James Bottomley 2019-07-01 15:06 ` David Howells 2 siblings, 0 replies; 106+ messages in thread From: James Bottomley @ 2019-06-28 21:07 UTC (permalink / raw) To: Shuah Khan, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-06-28 20:11 [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? Shuah Khan 2019-06-28 20:51 ` Luck, Tony 2019-06-28 21:07 ` James Bottomley @ 2019-07-01 15:06 ` David Howells 2019-07-01 15:40 ` Thomas Gleixner 2 siblings, 1 reply; 106+ messages in thread From: David Howells @ 2019-07-01 15:06 UTC (permalink / raw) To: Shuah Khan; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 15:06 ` David Howells @ 2019-07-01 15:40 ` Thomas Gleixner 2019-07-01 15:48 ` Laurent Pinchart 2019-07-01 15:50 ` James Bottomley 0 siblings, 2 replies; 106+ messages in thread From: Thomas Gleixner @ 2019-07-01 15:40 UTC (permalink / raw) To: David Howells; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 15:40 ` Thomas Gleixner @ 2019-07-01 15:48 ` Laurent Pinchart 2019-07-01 15:50 ` James Bottomley 1 sibling, 0 replies; 106+ messages in thread From: Laurent Pinchart @ 2019-07-01 15:48 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 15:40 ` Thomas Gleixner 2019-07-01 15:48 ` Laurent Pinchart @ 2019-07-01 15:50 ` James Bottomley 2019-07-01 17:54 ` Thomas Gleixner 1 sibling, 1 reply; 106+ messages in thread From: James Bottomley @ 2019-07-01 15:50 UTC (permalink / raw) To: Thomas Gleixner, David Howells; +Cc: ksummit-discuss 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 > ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 15:50 ` James Bottomley @ 2019-07-01 17:54 ` Thomas Gleixner 2019-07-02 14:20 ` James Bottomley 0 siblings, 1 reply; 106+ messages in thread From: Thomas Gleixner @ 2019-07-01 17:54 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-01 17:54 ` Thomas Gleixner @ 2019-07-02 14:20 ` James Bottomley 2019-07-02 14:49 ` Thomas Gleixner 0 siblings, 1 reply; 106+ messages in thread From: James Bottomley @ 2019-07-02 14:20 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 14:20 ` James Bottomley @ 2019-07-02 14:49 ` Thomas Gleixner 2019-07-02 15:10 ` James Bottomley 0 siblings, 1 reply; 106+ messages in thread From: Thomas Gleixner @ 2019-07-02 14:49 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 14:49 ` Thomas Gleixner @ 2019-07-02 15:10 ` James Bottomley 2019-07-02 15:18 ` James Bottomley ` (2 more replies) 0 siblings, 3 replies; 106+ messages in thread From: James Bottomley @ 2019-07-02 15:10 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 15:10 ` James Bottomley @ 2019-07-02 15:18 ` James Bottomley 2019-07-02 15:39 ` Shuah Khan 2019-07-02 15:30 ` Thomas Gleixner 2019-07-02 20:44 ` Jiri Kosina 2 siblings, 1 reply; 106+ messages in thread From: James Bottomley @ 2019-07-02 15:18 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 15:18 ` James Bottomley @ 2019-07-02 15:39 ` Shuah Khan 2019-07-02 15:51 ` James Bottomley 0 siblings, 1 reply; 106+ messages in thread From: Shuah Khan @ 2019-07-02 15:39 UTC (permalink / raw) To: James Bottomley, Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 15:39 ` Shuah Khan @ 2019-07-02 15:51 ` James Bottomley 2019-07-02 16:30 ` Kees Cook 2019-07-02 19:03 ` Shuah Khan 0 siblings, 2 replies; 106+ messages in thread From: James Bottomley @ 2019-07-02 15:51 UTC (permalink / raw) To: Shuah Khan, Thomas Gleixner; +Cc: ksummit-discuss 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 > ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 15:51 ` James Bottomley @ 2019-07-02 16:30 ` Kees Cook 2019-07-02 21:16 ` Konstantin Ryabitsev 2019-07-02 21:33 ` James Bottomley 2019-07-02 19:03 ` Shuah Khan 1 sibling, 2 replies; 106+ messages in thread From: Kees Cook @ 2019-07-02 16:30 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 16:30 ` Kees Cook @ 2019-07-02 21:16 ` Konstantin Ryabitsev 2019-07-02 21:33 ` James Bottomley 1 sibling, 0 replies; 106+ messages in thread From: Konstantin Ryabitsev @ 2019-07-02 21:16 UTC (permalink / raw) To: Kees Cook; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 16:30 ` Kees Cook 2019-07-02 21:16 ` Konstantin Ryabitsev @ 2019-07-02 21:33 ` James Bottomley 2019-07-02 22:07 ` Thomas Gleixner 1 sibling, 1 reply; 106+ messages in thread From: James Bottomley @ 2019-07-02 21:33 UTC (permalink / raw) To: Kees Cook; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 21:33 ` James Bottomley @ 2019-07-02 22:07 ` Thomas Gleixner 2019-07-02 22:26 ` James Bottomley 0 siblings, 1 reply; 106+ messages in thread From: Thomas Gleixner @ 2019-07-02 22:07 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 22:07 ` Thomas Gleixner @ 2019-07-02 22:26 ` James Bottomley 2019-07-02 22:43 ` Theodore Ts'o 2019-07-02 22:48 ` Thomas Gleixner 0 siblings, 2 replies; 106+ messages in thread From: James Bottomley @ 2019-07-02 22:26 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 22:26 ` James Bottomley @ 2019-07-02 22:43 ` Theodore Ts'o 2019-07-02 22:49 ` Thomas Gleixner ` (3 more replies) 2019-07-02 22:48 ` Thomas Gleixner 1 sibling, 4 replies; 106+ messages in thread From: Theodore Ts'o @ 2019-07-02 22:43 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 22:43 ` Theodore Ts'o @ 2019-07-02 22:49 ` Thomas Gleixner 2019-07-03 23:52 ` Ralf Ramsauer 2019-07-02 22:53 ` James Bottomley ` (2 subsequent siblings) 3 siblings, 1 reply; 106+ messages in thread From: Thomas Gleixner @ 2019-07-02 22:49 UTC (permalink / raw) To: Theodore Ts'o; +Cc: James Bottomley, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 22:49 ` Thomas Gleixner @ 2019-07-03 23:52 ` Ralf Ramsauer 0 siblings, 0 replies; 106+ messages in thread From: Ralf Ramsauer @ 2019-07-03 23:52 UTC (permalink / raw) To: Thomas Gleixner, Theodore Ts'o Cc: James Bottomley, Wolfgang Mauerer, mete.polat, ksummit-discuss, Lukas Bulwahn 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 22:43 ` Theodore Ts'o 2019-07-02 22:49 ` Thomas Gleixner @ 2019-07-02 22:53 ` James Bottomley 2019-07-02 23:12 ` Thomas Gleixner 2019-07-02 23:04 ` Kees Cook 2019-07-03 8:56 ` Laurent Pinchart 3 siblings, 1 reply; 106+ messages in thread From: James Bottomley @ 2019-07-02 22:53 UTC (permalink / raw) To: Theodore Ts'o; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 22:53 ` James Bottomley @ 2019-07-02 23:12 ` Thomas Gleixner 0 siblings, 0 replies; 106+ messages in thread From: Thomas Gleixner @ 2019-07-02 23:12 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 22:43 ` Theodore Ts'o 2019-07-02 22:49 ` Thomas Gleixner 2019-07-02 22:53 ` James Bottomley @ 2019-07-02 23:04 ` Kees Cook 2019-07-02 23:18 ` Theodore Ts'o 2019-07-03 8:56 ` Laurent Pinchart 3 siblings, 1 reply; 106+ messages in thread From: Kees Cook @ 2019-07-02 23:04 UTC (permalink / raw) To: Theodore Ts'o; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 23:04 ` Kees Cook @ 2019-07-02 23:18 ` Theodore Ts'o 2019-07-02 23:31 ` Kees Cook ` (2 more replies) 0 siblings, 3 replies; 106+ messages in thread From: Theodore Ts'o @ 2019-07-02 23:18 UTC (permalink / raw) To: Kees Cook; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 23:18 ` Theodore Ts'o @ 2019-07-02 23:31 ` Kees Cook 2019-07-02 23:33 ` James Bottomley 2019-07-02 23:41 ` Kees Cook 2 siblings, 0 replies; 106+ messages in thread From: Kees Cook @ 2019-07-02 23:31 UTC (permalink / raw) To: Theodore Ts'o; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 23:18 ` Theodore Ts'o 2019-07-02 23:31 ` Kees Cook @ 2019-07-02 23:33 ` James Bottomley 2019-07-03 4:16 ` Theodore Ts'o 2019-07-02 23:41 ` Kees Cook 2 siblings, 1 reply; 106+ messages in thread From: James Bottomley @ 2019-07-02 23:33 UTC (permalink / raw) To: Theodore Ts'o, Kees Cook; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 23:33 ` James Bottomley @ 2019-07-03 4:16 ` Theodore Ts'o 2019-07-03 4:50 ` James Bottomley 0 siblings, 1 reply; 106+ messages in thread From: Theodore Ts'o @ 2019-07-03 4:16 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 4:16 ` Theodore Ts'o @ 2019-07-03 4:50 ` James Bottomley 2019-07-03 14:42 ` Kees Cook 0 siblings, 1 reply; 106+ messages in thread From: James Bottomley @ 2019-07-03 4:50 UTC (permalink / raw) To: Theodore Ts'o; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 4:50 ` James Bottomley @ 2019-07-03 14:42 ` Kees Cook 0 siblings, 0 replies; 106+ messages in thread From: Kees Cook @ 2019-07-03 14:42 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 23:18 ` Theodore Ts'o 2019-07-02 23:31 ` Kees Cook 2019-07-02 23:33 ` James Bottomley @ 2019-07-02 23:41 ` Kees Cook 2019-07-03 7:51 ` Greg KH 2 siblings, 1 reply; 106+ messages in thread From: Kees Cook @ 2019-07-02 23:41 UTC (permalink / raw) To: Theodore Ts'o; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 23:41 ` Kees Cook @ 2019-07-03 7:51 ` Greg KH 0 siblings, 0 replies; 106+ messages in thread From: Greg KH @ 2019-07-03 7:51 UTC (permalink / raw) To: Kees Cook; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 22:43 ` Theodore Ts'o ` (2 preceding siblings ...) 2019-07-02 23:04 ` Kees Cook @ 2019-07-03 8:56 ` Laurent Pinchart 2019-07-03 9:12 ` Thomas Gleixner ` (3 more replies) 3 siblings, 4 replies; 106+ messages in thread From: Laurent Pinchart @ 2019-07-03 8:56 UTC (permalink / raw) To: Theodore Ts'o; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 8:56 ` Laurent Pinchart @ 2019-07-03 9:12 ` Thomas Gleixner 2019-07-03 12:39 ` Leon Romanovsky 2019-07-03 13:50 ` Theodore Ts'o ` (2 subsequent siblings) 3 siblings, 1 reply; 106+ messages in thread From: Thomas Gleixner @ 2019-07-03 9:12 UTC (permalink / raw) To: Laurent Pinchart; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 9:12 ` Thomas Gleixner @ 2019-07-03 12:39 ` Leon Romanovsky 2019-07-03 22:53 ` Laurent Pinchart 0 siblings, 1 reply; 106+ messages in thread From: Leon Romanovsky @ 2019-07-03 12:39 UTC (permalink / raw) To: Thomas Gleixner; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 12:39 ` Leon Romanovsky @ 2019-07-03 22:53 ` Laurent Pinchart 0 siblings, 0 replies; 106+ messages in thread From: Laurent Pinchart @ 2019-07-03 22:53 UTC (permalink / raw) To: Leon Romanovsky; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 8:56 ` Laurent Pinchart 2019-07-03 9:12 ` Thomas Gleixner @ 2019-07-03 13:50 ` Theodore Ts'o 2019-07-03 14:10 ` Jan Kara ` (2 more replies) 2019-07-03 23:03 ` James Bottomley 2019-07-05 9:03 ` Linus Walleij 3 siblings, 3 replies; 106+ messages in thread From: Theodore Ts'o @ 2019-07-03 13:50 UTC (permalink / raw) To: Laurent Pinchart; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 13:50 ` Theodore Ts'o @ 2019-07-03 14:10 ` Jan Kara 2019-07-03 17:05 ` Mark Brown 2019-07-03 19:11 ` Frank Rowand 2019-07-05 9:26 ` Linus Walleij 2 siblings, 1 reply; 106+ messages in thread From: Jan Kara @ 2019-07-03 14:10 UTC (permalink / raw) To: Theodore Ts'o; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 14:10 ` Jan Kara @ 2019-07-03 17:05 ` Mark Brown 0 siblings, 0 replies; 106+ messages in thread From: Mark Brown @ 2019-07-03 17:05 UTC (permalink / raw) To: Jan Kara; +Cc: James Bottomley, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 13:50 ` Theodore Ts'o 2019-07-03 14:10 ` Jan Kara @ 2019-07-03 19:11 ` Frank Rowand 2019-07-05 9:26 ` Linus Walleij 2 siblings, 0 replies; 106+ messages in thread From: Frank Rowand @ 2019-07-03 19:11 UTC (permalink / raw) To: Theodore Ts'o, Laurent Pinchart; +Cc: James Bottomley, ksummit-discuss 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 > ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 13:50 ` Theodore Ts'o 2019-07-03 14:10 ` Jan Kara 2019-07-03 19:11 ` Frank Rowand @ 2019-07-05 9:26 ` Linus Walleij 2019-07-05 19:34 ` Mike Rapoport 2019-07-06 4:42 ` Theodore Ts'o 2 siblings, 2 replies; 106+ messages in thread From: Linus Walleij @ 2019-07-05 9:26 UTC (permalink / raw) To: Theodore Ts'o, Marek Szyprowski; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-05 9:26 ` Linus Walleij @ 2019-07-05 19:34 ` Mike Rapoport 2019-07-06 4:42 ` Theodore Ts'o 1 sibling, 0 replies; 106+ messages in thread From: Mike Rapoport @ 2019-07-05 19:34 UTC (permalink / raw) To: Linus Walleij; +Cc: James Bottomley, ksummit-discuss, Marek Szyprowski 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. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-05 9:26 ` Linus Walleij 2019-07-05 19:34 ` Mike Rapoport @ 2019-07-06 4:42 ` Theodore Ts'o 2019-07-07 21:56 ` Frank Rowand 1 sibling, 1 reply; 106+ messages in thread From: Theodore Ts'o @ 2019-07-06 4:42 UTC (permalink / raw) To: Linus Walleij; +Cc: James Bottomley, ksummit-discuss, Marek Szyprowski 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-06 4:42 ` Theodore Ts'o @ 2019-07-07 21:56 ` Frank Rowand 0 siblings, 0 replies; 106+ messages in thread From: Frank Rowand @ 2019-07-07 21:56 UTC (permalink / raw) To: Theodore Ts'o, Linus Walleij Cc: James Bottomley, ksummit-discuss, Marek Szyprowski 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 > ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 8:56 ` Laurent Pinchart 2019-07-03 9:12 ` Thomas Gleixner 2019-07-03 13:50 ` Theodore Ts'o @ 2019-07-03 23:03 ` James Bottomley 2019-07-04 7:10 ` Geert Uytterhoeven 2019-07-05 9:03 ` Linus Walleij 3 siblings, 1 reply; 106+ messages in thread From: James Bottomley @ 2019-07-03 23:03 UTC (permalink / raw) To: Laurent Pinchart, Theodore Ts'o; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 23:03 ` James Bottomley @ 2019-07-04 7:10 ` Geert Uytterhoeven 0 siblings, 0 replies; 106+ messages in thread From: Geert Uytterhoeven @ 2019-07-04 7:10 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-03 8:56 ` Laurent Pinchart ` (2 preceding siblings ...) 2019-07-03 23:03 ` James Bottomley @ 2019-07-05 9:03 ` Linus Walleij 3 siblings, 0 replies; 106+ messages in thread From: Linus Walleij @ 2019-07-05 9:03 UTC (permalink / raw) To: Laurent Pinchart; +Cc: James Bottomley, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 22:26 ` James Bottomley 2019-07-02 22:43 ` Theodore Ts'o @ 2019-07-02 22:48 ` Thomas Gleixner 2019-07-02 23:05 ` James Bottomley 1 sibling, 1 reply; 106+ messages in thread From: Thomas Gleixner @ 2019-07-02 22:48 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 22:48 ` Thomas Gleixner @ 2019-07-02 23:05 ` James Bottomley 0 siblings, 0 replies; 106+ messages in thread From: James Bottomley @ 2019-07-02 23:05 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 15:51 ` James Bottomley 2019-07-02 16:30 ` Kees Cook @ 2019-07-02 19:03 ` Shuah Khan 1 sibling, 0 replies; 106+ messages in thread From: Shuah Khan @ 2019-07-02 19:03 UTC (permalink / raw) To: James Bottomley, Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 15:10 ` James Bottomley 2019-07-02 15:18 ` James Bottomley @ 2019-07-02 15:30 ` Thomas Gleixner 2019-07-02 15:40 ` James Bottomley 2019-07-02 20:44 ` Jiri Kosina 2 siblings, 1 reply; 106+ messages in thread From: Thomas Gleixner @ 2019-07-02 15:30 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 15:30 ` Thomas Gleixner @ 2019-07-02 15:40 ` James Bottomley 2019-07-02 15:49 ` Thomas Gleixner 0 siblings, 1 reply; 106+ messages in thread From: James Bottomley @ 2019-07-02 15:40 UTC (permalink / raw) To: Thomas Gleixner; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 15:40 ` James Bottomley @ 2019-07-02 15:49 ` Thomas Gleixner 0 siblings, 0 replies; 106+ messages in thread From: Thomas Gleixner @ 2019-07-02 15:49 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? 2019-07-02 15:10 ` James Bottomley 2019-07-02 15:18 ` James Bottomley 2019-07-02 15:30 ` Thomas Gleixner @ 2019-07-02 20:44 ` Jiri Kosina 2 siblings, 0 replies; 106+ messages in thread From: Jiri Kosina @ 2019-07-02 20:44 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 106+ messages in thread
end of thread, other threads:[~2019-08-08 5:25 UTC | newest] Thread overview: 106+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-28 20:11 [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? Shuah Khan 2019-06-28 20:51 ` Luck, Tony 2019-06-28 21:05 ` Kees Cook 2019-06-28 21:07 ` Shuah Khan 2019-06-28 21:13 ` James Bottomley 2019-06-28 21:42 ` Shuah Khan 2019-06-28 21:07 ` Wolfram Sang 2019-06-29 6:19 ` Thomas Gleixner 2019-06-29 9:10 ` Christian Brauner 2019-06-29 13:43 ` Andrea Parri 2019-06-29 15:16 ` Thomas Gleixner 2019-06-30 16:31 ` Konstantin Ryabitsev 2019-07-01 7:20 ` Peter Zijlstra 2019-07-01 7:49 ` Thomas Gleixner 2019-07-01 7:53 ` Takashi Iwai 2019-07-17 9:23 ` Dan Carpenter 2019-07-17 9:27 ` Dan Carpenter 2019-07-17 9:28 ` Greg KH 2019-07-17 16:09 ` Linus Walleij 2019-07-17 20:44 ` Greg KH 2019-07-18 9:09 ` Linus Walleij 2019-07-22 17:02 ` Kees Cook 2019-07-22 17:12 ` Joe Perches 2019-07-01 17:27 ` Steven Rostedt 2019-07-01 17:55 ` Thomas Gleixner 2019-07-01 9:48 ` Andrea Parri 2019-07-01 9:51 ` Andrea Parri 2019-07-02 4:40 ` Leon Romanovsky 2019-07-02 7:27 ` Geert Uytterhoeven 2019-07-02 9:48 ` Leon Romanovsky 2019-06-29 6:57 ` Takashi Iwai 2019-06-29 7:09 ` Thomas Gleixner 2019-06-29 7:18 ` Takashi Iwai 2019-06-29 11:20 ` Mark Brown 2019-06-30 16:01 ` Mauro Carvalho Chehab 2019-07-01 1:35 ` Andrew Donnellan 2019-07-01 11:10 ` Mark Brown 2019-08-08 5:24 ` Andrew Donnellan 2019-07-01 9:05 ` Jiri Kosina 2019-07-01 9:15 ` Sergey Senozhatsky 2019-07-04 12:15 ` Michael Ellerman 2019-07-04 13:24 ` Geert Uytterhoeven 2019-07-04 14:16 ` Thomas Gleixner 2019-07-05 3:37 ` Michael Ellerman 2019-07-05 4:10 ` Michael Ellerman 2019-07-05 6:28 ` Thomas Gleixner 2019-07-05 8:24 ` Geert Uytterhoeven 2019-07-04 14:22 ` James Bottomley 2019-07-05 3:24 ` Michael Ellerman 2019-07-06 14:02 ` Alexandre Belloni 2019-07-06 14:57 ` James Bottomley 2019-07-05 3:40 ` Michael Ellerman 2019-07-05 8:40 ` Geert Uytterhoeven 2019-06-28 21:07 ` James Bottomley 2019-07-01 15:06 ` David Howells 2019-07-01 15:40 ` Thomas Gleixner 2019-07-01 15:48 ` Laurent Pinchart 2019-07-01 15:50 ` James Bottomley 2019-07-01 17:54 ` Thomas Gleixner 2019-07-02 14:20 ` James Bottomley 2019-07-02 14:49 ` Thomas Gleixner 2019-07-02 15:10 ` James Bottomley 2019-07-02 15:18 ` James Bottomley 2019-07-02 15:39 ` Shuah Khan 2019-07-02 15:51 ` James Bottomley 2019-07-02 16:30 ` Kees Cook 2019-07-02 21:16 ` Konstantin Ryabitsev 2019-07-02 21:33 ` James Bottomley 2019-07-02 22:07 ` Thomas Gleixner 2019-07-02 22:26 ` James Bottomley 2019-07-02 22:43 ` Theodore Ts'o 2019-07-02 22:49 ` Thomas Gleixner 2019-07-03 23:52 ` Ralf Ramsauer 2019-07-02 22:53 ` James Bottomley 2019-07-02 23:12 ` Thomas Gleixner 2019-07-02 23:04 ` Kees Cook 2019-07-02 23:18 ` Theodore Ts'o 2019-07-02 23:31 ` Kees Cook 2019-07-02 23:33 ` James Bottomley 2019-07-03 4:16 ` Theodore Ts'o 2019-07-03 4:50 ` James Bottomley 2019-07-03 14:42 ` Kees Cook 2019-07-02 23:41 ` Kees Cook 2019-07-03 7:51 ` Greg KH 2019-07-03 8:56 ` Laurent Pinchart 2019-07-03 9:12 ` Thomas Gleixner 2019-07-03 12:39 ` Leon Romanovsky 2019-07-03 22:53 ` Laurent Pinchart 2019-07-03 13:50 ` Theodore Ts'o 2019-07-03 14:10 ` Jan Kara 2019-07-03 17:05 ` Mark Brown 2019-07-03 19:11 ` Frank Rowand 2019-07-05 9:26 ` Linus Walleij 2019-07-05 19:34 ` Mike Rapoport 2019-07-06 4:42 ` Theodore Ts'o 2019-07-07 21:56 ` Frank Rowand 2019-07-03 23:03 ` James Bottomley 2019-07-04 7:10 ` Geert Uytterhoeven 2019-07-05 9:03 ` Linus Walleij 2019-07-02 22:48 ` Thomas Gleixner 2019-07-02 23:05 ` James Bottomley 2019-07-02 19:03 ` Shuah Khan 2019-07-02 15:30 ` Thomas Gleixner 2019-07-02 15:40 ` James Bottomley 2019-07-02 15:49 ` Thomas Gleixner 2019-07-02 20:44 ` Jiri Kosina
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.