Ksummit-Discuss Archive on lore.kernel.org
 help / color / Atom feed
* [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
@ 2019-08-22 23:39 Doug Anderson
  2019-08-23  0:03 ` Brendan Higgins
                   ` (2 more replies)
  0 siblings, 3 replies; 105+ messages in thread
From: Doug Anderson @ 2019-08-22 23:39 UTC (permalink / raw)
  To: ksummit-discuss
  Cc: Joel Fernandes, Barret Rhoden, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Brendan Higgins, Han-Wen Nienhuys,
	Theodore Tso, David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi,

As everyone is probably aware, when you use the gerrit code review
system all of your commits get an extra line in them that looks
something like:

Change-Id: I6a007dfe91ee1077a437963cf26d91370fdd9556

The Linux kernel has always viewed these Change-Id tags as obnoxious
and useless spam.  Anyone who accidentally leaves a Change-Id in their
patch when posting to the mailing list is told to please re-post their
patch without the Change-Id.  In this email, I will attempt to argue
that the Linux kernel ought to relax this restriction and allow
(possibly even encourage) Change-Ids.


To begin with, let me make sure we're on the same page about what
Change-Ids are.  As I understand it:

* A change ID is much alike a UUID.  It is locally generated on a
developer's computer and is (in theory) unique across the universe.

* When a developer keeps the same Change-Id across two patches they
are making the assertion that the two patches are either the same or
should be treated as two versions of the same logical change.  For
instance, v1, v2, and v3 of the same patch should have the same
Change-Id.  Even if v2 and v3 of the patch have different subjects and
touch different files, if they have the same Change-Id then the
developer is asserting that v3 should be considered a new version of
the same logical change as v2.  If it helps to think about it,
Change-Id is used by gerrit servers to know that a new patch uploaded
should replace an older version with the same Change-Id.


At the moment, Change-Ids are highly associated in people's minds with
gerrit and many upstream developers dislike gerrit.  To be clear: I am
not suggesting that kernel developers should endorse gerrit or be
forced to use gerrit.  I am suggesting that the idea of Change-Ids is
a good one independent of gerrit.  If we start using Change-Id then it
will allow better tools to be created, making life better for kernel
developers.


Specifically, let me list the problems I'd like to solve:

1. If I see a commit in Linux, I would like to be able to easily find
all of the mailing list discussions relevant to that commit.  I know
there are proposals about including the Message-Id of the final post
in the commit log and that is certainly better than nothing, but the
Message-Id will only get you a link to the final version of the patch.
If the relevant discussion happened on a previous version of that
patch then you need to find it yourself.  This gets harder if the
patch changed subject, touched different files, if parts of the series
landed at different times, and if multiple people were involved in
posting different versions of the patch.  If the commit in Linux has a
Change-Id then the old versions are logically linked and easier to
associated with one another.

2. If I do a search through old mailing list archives and I stumble
upon a patch that didn't land, I can more easily find different
versions of that patch if I have a Change-Id.  Some of these different
versions may have relevant discussions that explains why the patch
didn't land.  Finding these other patches without a Change-Id might be
hard, again because they may touch different files, have a different
subject, or have been posted by a different person.


At the moment using a Change-Id in the way I described would require
searching through mailing lists for the Change-Id string to find other
versions of the same patch.  However, I would expect it would only be
a matter of time before tools like patchwork are able to use Change-Id
to associate one version of a patch with the next version.  I would
also expect that allowing Change-Id to exist would allow someone to
(perhaps) create a gerrit instance that watched the kernel mailing
list and mirrored mailing list discussions in the GUI.  In other
words, once such tools exist presumably Change-Id will be much more
useful: you will eventually be able to paste a Change-Id into a tool
and get links to all relevant discussion and related posts.


The basic summary is that I'd like there to be some way to track a
logical patch over its lifetime.  I don't believe there is a reliable
(non-heuristic) way to do this today and I think Change-Id provides a
nice solution.  While we could come up with a new and different
solution (because Change-Id was not invented here), it feels like
adopting Change-Id is convenient and easy and provides a true benefit.
Change-Id works super well with the decentralized/email workflow for
patches and can be phased in over time (or it can stay optional
forever).


Thank you for reading

-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-22 23:39 [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits Doug Anderson
@ 2019-08-23  0:03 ` Brendan Higgins
  2019-08-23  0:17 ` Linus Torvalds
  2019-09-05  8:12 ` Eric Wong
  2 siblings, 0 replies; 105+ messages in thread
From: Brendan Higgins @ 2019-08-23  0:03 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit-discuss,
	Greg Kroah-Hartman, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Torokhov,
	Dmitry Vyukov

On Thu, Aug 22, 2019 at 4:40 PM Doug Anderson <dianders@chromium.org> wrote:
[...]
> Specifically, let me list the problems I'd like to solve:
>
> 1. If I see a commit in Linux, I would like to be able to easily find
> all of the mailing list discussions relevant to that commit.  I know
> there are proposals about including the Message-Id of the final post
> in the commit log and that is certainly better than nothing, but the
> Message-Id will only get you a link to the final version of the patch.
> If the relevant discussion happened on a previous version of that
> patch then you need to find it yourself.  This gets harder if the
> patch changed subject, touched different files, if parts of the series
> landed at different times, and if multiple people were involved in
> posting different versions of the patch.  If the commit in Linux has a
> Change-Id then the old versions are logically linked and easier to
> associated with one another.

Please correct me if I am wrong, but I believe this feature already
exists in cregit[1]. I believe this is called Email2git[2].

To be clear, I am not against the Change-Id tag, but I think we
already have support for what you are describing here.

> 2. If I do a search through old mailing list archives and I stumble
> upon a patch that didn't land, I can more easily find different
> versions of that patch if I have a Change-Id.  Some of these different
> versions may have relevant discussions that explains why the patch
> didn't land.  Finding these other patches without a Change-Id might be
> hard, again because they may touch different files, have a different
> subject, or have been posted by a different person.

Yes! I would love this, and I don't think Email2git handles this;
nevertheless, I am not sure how difficult it would be to add support
for that to Email2git.

>
> At the moment using a Change-Id in the way I described would require
> searching through mailing lists for the Change-Id string to find other
> versions of the same patch.  However, I would expect it would only be
> a matter of time before tools like patchwork are able to use Change-Id
> to associate one version of a patch with the next version.  I would
> also expect that allowing Change-Id to exist would allow someone to
> (perhaps) create a gerrit instance that watched the kernel mailing
> list and mirrored mailing list discussions in the GUI.  In other
> words, once such tools exist presumably Change-Id will be much more
> useful: you will eventually be able to paste a Change-Id into a tool
> and get links to all relevant discussion and related posts.
>
>
> The basic summary is that I'd like there to be some way to track a
> logical patch over its lifetime.  I don't believe there is a reliable
> (non-heuristic) way to do this today and I think Change-Id provides a

I am not sure what Email2git does (I assume it uses a heuristic), but
it seems reasonably reliable after a couple of random spot checks.

> nice solution.  While we could come up with a new and different
> solution (because Change-Id was not invented here), it feels like
> adopting Change-Id is convenient and easy and provides a true benefit.
> Change-Id works super well with the decentralized/email workflow for
> patches and can be phased in over time (or it can stay optional
> forever).

I have wanted to do some of this tracking a commit across multiple
revisions and I have not found a simple way to do it. I keep meaning
to look into Email2git more closely, but it is hard for me to imagine
something more straightforward than something analogous to a
Change-Id.

So I like the idea, but I think it is probably worth first
investigating Email2git and see if it solves the same use case. If
Email2git is portable and is easy to build into a workflow outside of
cregit, then it should be equally easy to represent the metadata that
Change-Id provides outside of the mailing lists.

Thanks for thinking about this!

[1] https://cregit.linuxsources.org
[2] https://www.linux.com/tutorials/email2git-matching-linux-code-its-mailing-list-discussions/

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-22 23:39 [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits Doug Anderson
  2019-08-23  0:03 ` Brendan Higgins
@ 2019-08-23  0:17 ` Linus Torvalds
  2019-08-23  0:30   ` Olof Johansson
                     ` (2 more replies)
  2019-09-05  8:12 ` Eric Wong
  2 siblings, 3 replies; 105+ messages in thread
From: Linus Torvalds @ 2019-08-23  0:17 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	Dmitry Vyukov, David Rientjes, Dmitry Torokhov

On Thu, Aug 22, 2019 at 4:40 PM Doug Anderson <dianders@chromium.org> wrote:
>
> The Linux kernel has always viewed these Change-Id tags as obnoxious
> and useless spam.  Anyone who accidentally leaves a Change-Id in their
> patch when posting to the mailing list is told to please re-post their
> patch without the Change-Id.  In this email, I will attempt to argue
> that the Linux kernel ought to relax this restriction and allow
> (possibly even encourage) Change-Ids.

No.

Not without some ground rules.

> To begin with, let me make sure we're on the same page about what
> Change-Ids are.  As I understand it:
>
> * A change ID is much alike a UUID.  It is locally generated on a
> developer's computer and is (in theory) unique across the universe.

Completely irrelevant.

The point of an UUID is not just that it's unique, but THAT YOU CAN
LOOK SOMETHING UP USING IT!

A "change ID" that I can't use to look anything up with is completely
pointless and should be removed from kernel history.

But if you have something unique that is actually useful for looking
things up, then by all means. But it needs to be useful for
_everybody_.

> * When a developer keeps the same Change-Id across two patches they
> are making the assertion that the two patches are either the same or
> should be treated as two versions of the same logical change.

.. and we have better ways to do that.

For example, we are actively encouraging things like message ID's
(which are _also_ a form of locally generated UUID, they just are more
than the silly purely numerical one).

That gives you the origin of something, but it also gives you the
development history and context.

But note that how when it comes to message ID's we encourage them in a
form that actually also helps look that information up, ie the
preferred form isn't just the message ID (although that exists), it's
a link like

    Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org

instead of

   Message-ID: 20190723065733.4899-5-leon@kernel.org

even though technically they have just as much actual information in theory.

Do you see people complaining about that kind of UUID? No.  Because it
gives useful information to the project, and when something happens,
people can look things up and _use_ that kind of UUID.

> At the moment, Change-Ids are highly associated in people's minds with
> gerrit and many upstream developers dislike gerrit.

No. That's not it at all. It's not "dislike gerrit".

It's "dislike pointless garbage".

If the gerrit database is public and searchable using the uuid, then
that would make the uuid useful to outsiders. And instead of just
putting a UUID (which is hard to look up unless you know where it came
from), make it be that "Link:" that gives not just the UUID, but also
gives you the metadata for that UUID to be looked up.

But so far, in every single case the uuid's I've ever seen have been
pointless garbage, that aren't useful in general to public open source
developers, and as such shouldn't be in the git tree.

See the difference?

So if you guys make the gerrit database actually public, and then
start adding "Link: ..." tags so that we can see what they point to, I
think people will be more than supportive of it.

But if it's some stupid and pointless UUID that is useful to nobody
outside of google (or special magical groups of people associated with
it), then I will personally continue to be very much against it.

If it's some internal database for your exclusive club, then you can
just have your own internal database to look that UUID up using a
commit ID (or a patch ID that is generated from the patch), and you
don't need to pollute the public with non-public noise.

Do people do that "pointless pullution" thing? Yes, I've seen various
companies add their garbage to the commit logs. Sometimes it makes it
through. But if I see an email with random noise in it, I will
personally remove that random useless noise.

This is part of what "open source" is all about. There aren't supposed
to be special people with access to inside information that get
preferential treatment. If you have your private stuff, then fine, but
keep it private. It has no business being in the public tree.

            Linus

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  0:17 ` Linus Torvalds
@ 2019-08-23  0:30   ` Olof Johansson
  2019-08-23  0:43     ` Guenter Roeck
  2019-08-23  1:01   ` Dmitry Torokhov
  2019-08-23  1:07   ` Doug Anderson
  2 siblings, 1 reply; 105+ messages in thread
From: Olof Johansson @ 2019-08-23  0:30 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Thu, Aug 22, 2019 at 5:17 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Thu, Aug 22, 2019 at 4:40 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > The Linux kernel has always viewed these Change-Id tags as obnoxious
> > and useless spam.  Anyone who accidentally leaves a Change-Id in their
> > patch when posting to the mailing list is told to please re-post their
> > patch without the Change-Id.  In this email, I will attempt to argue
> > that the Linux kernel ought to relax this restriction and allow
> > (possibly even encourage) Change-Ids.
>
> No.
>
> Not without some ground rules.
>
> > To begin with, let me make sure we're on the same page about what
> > Change-Ids are.  As I understand it:
> >
> > * A change ID is much alike a UUID.  It is locally generated on a
> > developer's computer and is (in theory) unique across the universe.
>
> Completely irrelevant.
>
> The point of an UUID is not just that it's unique, but THAT YOU CAN
> LOOK SOMETHING UP USING IT!
>
> A "change ID" that I can't use to look anything up with is completely
> pointless and should be removed from kernel history.
>
> But if you have something unique that is actually useful for looking
> things up, then by all means. But it needs to be useful for
> _everybody_.
>
> > * When a developer keeps the same Change-Id across two patches they
> > are making the assertion that the two patches are either the same or
> > should be treated as two versions of the same logical change.
>
> .. and we have better ways to do that.
>
> For example, we are actively encouraging things like message ID's
> (which are _also_ a form of locally generated UUID, they just are more
> than the silly purely numerical one).
>
> That gives you the origin of something, but it also gives you the
> development history and context.
>
> But note that how when it comes to message ID's we encourage them in a
> form that actually also helps look that information up, ie the
> preferred form isn't just the message ID (although that exists), it's
> a link like
>
>     Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org
>
> instead of
>
>    Message-ID: 20190723065733.4899-5-leon@kernel.org
>
> even though technically they have just as much actual information in theory.
>
> Do you see people complaining about that kind of UUID? No.  Because it
> gives useful information to the project, and when something happens,
> people can look things up and _use_ that kind of UUID.

For the actual open projects, the answer to this might be relative
easy: Most gerrit instances can feed a mailing list with emails of
both the initial patch, and later comments.

Said emails would obviously have a Message-ID, and if the list is
added to lore, it can be referenced there.

Note, even if the Change-Id had a full URL, there would be no archival
guarantee in the same way as lore gives us, so that approach alone
isn't useful. A URL to a "forever" mailing list archive seems like the
most stable possible reference.

This doesn't address the full issue Doug was looking to solve, which
is the reverse mapping of "posted patch" to "previous version of the
patch". Patchwork tries to guess this, but it's best effort. I don't
have a great answer to this, besides possibly in-reply-to threading
and associating back that way via the email trail.


-Oloif

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  0:30   ` Olof Johansson
@ 2019-08-23  0:43     ` Guenter Roeck
  2019-08-23  0:45       ` Olof Johansson
  0 siblings, 1 reply; 105+ messages in thread
From: Guenter Roeck @ 2019-08-23  0:43 UTC (permalink / raw)
  To: Olof Johansson, Linus Torvalds
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On 8/22/19 5:30 PM, Olof Johansson wrote:
> On Thu, Aug 22, 2019 at 5:17 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> On Thu, Aug 22, 2019 at 4:40 PM Doug Anderson <dianders@chromium.org> wrote:
>>>
>>> The Linux kernel has always viewed these Change-Id tags as obnoxious
>>> and useless spam.  Anyone who accidentally leaves a Change-Id in their
>>> patch when posting to the mailing list is told to please re-post their
>>> patch without the Change-Id.  In this email, I will attempt to argue
>>> that the Linux kernel ought to relax this restriction and allow
>>> (possibly even encourage) Change-Ids.
>>
>> No.
>>
>> Not without some ground rules.
>>
>>> To begin with, let me make sure we're on the same page about what
>>> Change-Ids are.  As I understand it:
>>>
>>> * A change ID is much alike a UUID.  It is locally generated on a
>>> developer's computer and is (in theory) unique across the universe.
>>
>> Completely irrelevant.
>>
>> The point of an UUID is not just that it's unique, but THAT YOU CAN
>> LOOK SOMETHING UP USING IT!
>>
>> A "change ID" that I can't use to look anything up with is completely
>> pointless and should be removed from kernel history.
>>
>> But if you have something unique that is actually useful for looking
>> things up, then by all means. But it needs to be useful for
>> _everybody_.
>>
>>> * When a developer keeps the same Change-Id across two patches they
>>> are making the assertion that the two patches are either the same or
>>> should be treated as two versions of the same logical change.
>>
>> .. and we have better ways to do that.
>>
>> For example, we are actively encouraging things like message ID's
>> (which are _also_ a form of locally generated UUID, they just are more
>> than the silly purely numerical one).
>>
>> That gives you the origin of something, but it also gives you the
>> development history and context.
>>
>> But note that how when it comes to message ID's we encourage them in a
>> form that actually also helps look that information up, ie the
>> preferred form isn't just the message ID (although that exists), it's
>> a link like
>>
>>      Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org
>>
>> instead of
>>
>>     Message-ID: 20190723065733.4899-5-leon@kernel.org
>>
>> even though technically they have just as much actual information in theory.
>>
>> Do you see people complaining about that kind of UUID? No.  Because it
>> gives useful information to the project, and when something happens,
>> people can look things up and _use_ that kind of UUID.
> 
> For the actual open projects, the answer to this might be relative
> easy: Most gerrit instances can feed a mailing list with emails of
> both the initial patch, and later comments.
> 
> Said emails would obviously have a Message-ID, and if the list is
> added to lore, it can be referenced there.
> 
> Note, even if the Change-Id had a full URL, there would be no archival
> guarantee in the same way as lore gives us, so that approach alone
> isn't useful. A URL to a "forever" mailing list archive seems like the
> most stable possible reference.
> 
> This doesn't address the full issue Doug was looking to solve, which
> is the reverse mapping of "posted patch" to "previous version of the
> patch". Patchwork tries to guess this, but it's best effort. I don't
> have a great answer to this, besides possibly in-reply-to threading
> and associating back that way via the email trail.
> 

Wouldn't a direct link to the Gerrit instance solve the problem ?
After all,

Link: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1759334

points to the same Gerrit entry as

Change-Id: I5a2e33424e7fb19fed13afb854ae6546ef9bfa35

and there would be no need to look anything up.

Guenter

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  0:43     ` Guenter Roeck
@ 2019-08-23  0:45       ` Olof Johansson
  2019-08-23  1:05         ` Olof Johansson
  2019-08-23  1:36         ` Theodore Y. Ts'o
  0 siblings, 2 replies; 105+ messages in thread
From: Olof Johansson @ 2019-08-23  0:45 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Joel Fernandes, Barret Rhoden, Dmitry Torokhov, ksummit,
	Greg Kroah-Hartman, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Vyukov

On Thu, Aug 22, 2019 at 5:43 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 8/22/19 5:30 PM, Olof Johansson wrote:
> > On Thu, Aug 22, 2019 at 5:17 PM Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> >>
> >> On Thu, Aug 22, 2019 at 4:40 PM Doug Anderson <dianders@chromium.org> wrote:
> >>>
> >>> The Linux kernel has always viewed these Change-Id tags as obnoxious
> >>> and useless spam.  Anyone who accidentally leaves a Change-Id in their
> >>> patch when posting to the mailing list is told to please re-post their
> >>> patch without the Change-Id.  In this email, I will attempt to argue
> >>> that the Linux kernel ought to relax this restriction and allow
> >>> (possibly even encourage) Change-Ids.
> >>
> >> No.
> >>
> >> Not without some ground rules.
> >>
> >>> To begin with, let me make sure we're on the same page about what
> >>> Change-Ids are.  As I understand it:
> >>>
> >>> * A change ID is much alike a UUID.  It is locally generated on a
> >>> developer's computer and is (in theory) unique across the universe.
> >>
> >> Completely irrelevant.
> >>
> >> The point of an UUID is not just that it's unique, but THAT YOU CAN
> >> LOOK SOMETHING UP USING IT!
> >>
> >> A "change ID" that I can't use to look anything up with is completely
> >> pointless and should be removed from kernel history.
> >>
> >> But if you have something unique that is actually useful for looking
> >> things up, then by all means. But it needs to be useful for
> >> _everybody_.
> >>
> >>> * When a developer keeps the same Change-Id across two patches they
> >>> are making the assertion that the two patches are either the same or
> >>> should be treated as two versions of the same logical change.
> >>
> >> .. and we have better ways to do that.
> >>
> >> For example, we are actively encouraging things like message ID's
> >> (which are _also_ a form of locally generated UUID, they just are more
> >> than the silly purely numerical one).
> >>
> >> That gives you the origin of something, but it also gives you the
> >> development history and context.
> >>
> >> But note that how when it comes to message ID's we encourage them in a
> >> form that actually also helps look that information up, ie the
> >> preferred form isn't just the message ID (although that exists), it's
> >> a link like
> >>
> >>      Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org
> >>
> >> instead of
> >>
> >>     Message-ID: 20190723065733.4899-5-leon@kernel.org
> >>
> >> even though technically they have just as much actual information in theory.
> >>
> >> Do you see people complaining about that kind of UUID? No.  Because it
> >> gives useful information to the project, and when something happens,
> >> people can look things up and _use_ that kind of UUID.
> >
> > For the actual open projects, the answer to this might be relative
> > easy: Most gerrit instances can feed a mailing list with emails of
> > both the initial patch, and later comments.
> >
> > Said emails would obviously have a Message-ID, and if the list is
> > added to lore, it can be referenced there.
> >
> > Note, even if the Change-Id had a full URL, there would be no archival
> > guarantee in the same way as lore gives us, so that approach alone
> > isn't useful. A URL to a "forever" mailing list archive seems like the
> > most stable possible reference.
> >
> > This doesn't address the full issue Doug was looking to solve, which
> > is the reverse mapping of "posted patch" to "previous version of the
> > patch". Patchwork tries to guess this, but it's best effort. I don't
> > have a great answer to this, besides possibly in-reply-to threading
> > and associating back that way via the email trail.
> >
>
> Wouldn't a direct link to the Gerrit instance solve the problem ?
> After all,
>
> Link: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1759334
>
> points to the same Gerrit entry as
>
> Change-Id: I5a2e33424e7fb19fed13afb854ae6546ef9bfa35
>
> and there would be no need to look anything up.

Nope, for the same reason I already mentioned: In 2 years when Google
deprecates Chromium and EOL's the product and project (see: Reader,
Google+, Youtube messaging), there will be no way to get to the
history. (I know, unlikely in this case, but URLs move without
redirects, etc).

Lore solves that, since it's externally archived.


-Olof

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  0:17 ` Linus Torvalds
  2019-08-23  0:30   ` Olof Johansson
@ 2019-08-23  1:01   ` Dmitry Torokhov
  2019-08-23  1:07   ` Doug Anderson
  2 siblings, 0 replies; 105+ messages in thread
From: Dmitry Torokhov @ 2019-08-23  1:01 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Thu, Aug 22, 2019 at 05:17:05PM -0700, Linus Torvalds wrote:
> On Thu, Aug 22, 2019 at 4:40 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > The Linux kernel has always viewed these Change-Id tags as obnoxious
> > and useless spam.  Anyone who accidentally leaves a Change-Id in their
> > patch when posting to the mailing list is told to please re-post their
> > patch without the Change-Id.  In this email, I will attempt to argue
> > that the Linux kernel ought to relax this restriction and allow
> > (possibly even encourage) Change-Ids.
> 
> No.
> 
> Not without some ground rules.
> 
> > To begin with, let me make sure we're on the same page about what
> > Change-Ids are.  As I understand it:
> >
> > * A change ID is much alike a UUID.  It is locally generated on a
> > developer's computer and is (in theory) unique across the universe.
> 
> Completely irrelevant.
> 
> The point of an UUID is not just that it's unique, but THAT YOU CAN
> LOOK SOMETHING UP USING IT!
> 
> A "change ID" that I can't use to look anything up with is completely
> pointless and should be removed from kernel history.
> 
> But if you have something unique that is actually useful for looking
> things up, then by all means. But it needs to be useful for
> _everybody_.

It can be used by anybody. At the barest minimum, one can simply google
it and get results from emails sent to LKML and other lists. Maybe down
the road patchwork will learn to use it.

BTW, I am not sure if we want a patch ID or series ID that is stable
across patch series.

> 
> > * When a developer keeps the same Change-Id across two patches they
> > are making the assertion that the two patches are either the same or
> > should be treated as two versions of the same logical change.
> 
> .. and we have better ways to do that.
> 
> For example, we are actively encouraging things like message ID's
> (which are _also_ a form of locally generated UUID, they just are more
> than the silly purely numerical one).
> 
> That gives you the origin of something, but it also gives you the
> development history and context.

But not all of it, as when somebody posts v2, v3, v4 of the patch series
the emails will generate new message IDs, so we lose connection to the
old discussions. With new unique ID that is preserved for the entire
lifetime of patch series it is much easier to locate all relevant data.

Thanks.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  0:45       ` Olof Johansson
@ 2019-08-23  1:05         ` Olof Johansson
  2019-08-23  1:09           ` Dmitry Torokhov
  2019-08-23  1:36         ` Theodore Y. Ts'o
  1 sibling, 1 reply; 105+ messages in thread
From: Olof Johansson @ 2019-08-23  1:05 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Joel Fernandes, Barret Rhoden, Dmitry Torokhov, ksummit,
	Greg Kroah-Hartman, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Vyukov

On Thu, Aug 22, 2019 at 5:45 PM Olof Johansson <olof@lixom.net> wrote:
>
> On Thu, Aug 22, 2019 at 5:43 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On 8/22/19 5:30 PM, Olof Johansson wrote:
> > > On Thu, Aug 22, 2019 at 5:17 PM Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > >>
> > >> On Thu, Aug 22, 2019 at 4:40 PM Doug Anderson <dianders@chromium.org> wrote:
> > >>>
> > >>> The Linux kernel has always viewed these Change-Id tags as obnoxious
> > >>> and useless spam.  Anyone who accidentally leaves a Change-Id in their
> > >>> patch when posting to the mailing list is told to please re-post their
> > >>> patch without the Change-Id.  In this email, I will attempt to argue
> > >>> that the Linux kernel ought to relax this restriction and allow
> > >>> (possibly even encourage) Change-Ids.
> > >>
> > >> No.
> > >>
> > >> Not without some ground rules.
> > >>
> > >>> To begin with, let me make sure we're on the same page about what
> > >>> Change-Ids are.  As I understand it:
> > >>>
> > >>> * A change ID is much alike a UUID.  It is locally generated on a
> > >>> developer's computer and is (in theory) unique across the universe.
> > >>
> > >> Completely irrelevant.
> > >>
> > >> The point of an UUID is not just that it's unique, but THAT YOU CAN
> > >> LOOK SOMETHING UP USING IT!
> > >>
> > >> A "change ID" that I can't use to look anything up with is completely
> > >> pointless and should be removed from kernel history.
> > >>
> > >> But if you have something unique that is actually useful for looking
> > >> things up, then by all means. But it needs to be useful for
> > >> _everybody_.
> > >>
> > >>> * When a developer keeps the same Change-Id across two patches they
> > >>> are making the assertion that the two patches are either the same or
> > >>> should be treated as two versions of the same logical change.
> > >>
> > >> .. and we have better ways to do that.
> > >>
> > >> For example, we are actively encouraging things like message ID's
> > >> (which are _also_ a form of locally generated UUID, they just are more
> > >> than the silly purely numerical one).
> > >>
> > >> That gives you the origin of something, but it also gives you the
> > >> development history and context.
> > >>
> > >> But note that how when it comes to message ID's we encourage them in a
> > >> form that actually also helps look that information up, ie the
> > >> preferred form isn't just the message ID (although that exists), it's
> > >> a link like
> > >>
> > >>      Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org
> > >>
> > >> instead of
> > >>
> > >>     Message-ID: 20190723065733.4899-5-leon@kernel.org
> > >>
> > >> even though technically they have just as much actual information in theory.
> > >>
> > >> Do you see people complaining about that kind of UUID? No.  Because it
> > >> gives useful information to the project, and when something happens,
> > >> people can look things up and _use_ that kind of UUID.
> > >
> > > For the actual open projects, the answer to this might be relative
> > > easy: Most gerrit instances can feed a mailing list with emails of
> > > both the initial patch, and later comments.
> > >
> > > Said emails would obviously have a Message-ID, and if the list is
> > > added to lore, it can be referenced there.
> > >
> > > Note, even if the Change-Id had a full URL, there would be no archival
> > > guarantee in the same way as lore gives us, so that approach alone
> > > isn't useful. A URL to a "forever" mailing list archive seems like the
> > > most stable possible reference.
> > >
> > > This doesn't address the full issue Doug was looking to solve, which
> > > is the reverse mapping of "posted patch" to "previous version of the
> > > patch". Patchwork tries to guess this, but it's best effort. I don't
> > > have a great answer to this, besides possibly in-reply-to threading
> > > and associating back that way via the email trail.
> > >
> >
> > Wouldn't a direct link to the Gerrit instance solve the problem ?
> > After all,
> >
> > Link: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1759334
> >
> > points to the same Gerrit entry as
> >
> > Change-Id: I5a2e33424e7fb19fed13afb854ae6546ef9bfa35
> >
> > and there would be no need to look anything up.
>
> Nope, for the same reason I already mentioned: In 2 years when Google
> deprecates Chromium and EOL's the product and project (see: Reader,
> Google+, Youtube messaging), there will be no way to get to the
> history. (I know, unlikely in this case, but URLs move without
> redirects, etc).
>
> Lore solves that, since it's externally archived.

Actually, it seems like the outgoing email already has suitable headers.

I looked up a random review, and viewed raw message:

https://groups.google.com/a/chromium.org/forum/#!original/chromium-os-reviews/Y2R_LLKytQw/M0TRRzfoAgAJ

X-Gerrit-Change-Id: I50d72612569743198825afdf41200c15db759076
X-Gerrit-Change-Number: 1762035
X-Gerrit-ChangeURL:
<https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1762035>
X-Gerrit-Commit: 5b7dff2b2cb0b1a8769a53d59e387772ae569243

Since that would be captured in a mail archive, you could easily get
it from there if needed.

Based on this, there's no reason to use opaque Change-Id, all the
functionality needed can be reached through the mail URLs we already
agreed are reasonable to use.


(Someone should maybe tell Hao that he has the email address
misspelled in his S-o-b).


-Olof

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  0:17 ` Linus Torvalds
  2019-08-23  0:30   ` Olof Johansson
  2019-08-23  1:01   ` Dmitry Torokhov
@ 2019-08-23  1:07   ` Doug Anderson
  2019-08-23  1:18     ` Joel Fernandes
  2 siblings, 1 reply; 105+ messages in thread
From: Doug Anderson @ 2019-08-23  1:07 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	Dmitry Vyukov, David Rientjes, Dmitry Torokhov

Hi,

On Thu, Aug 22, 2019 at 5:17 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> > To begin with, let me make sure we're on the same page about what
> > Change-Ids are.  As I understand it:
> >
> > * A change ID is much alike a UUID.  It is locally generated on a
> > developer's computer and is (in theory) unique across the universe.
>
> Completely irrelevant.
>
> The point of an UUID is not just that it's unique, but THAT YOU CAN
> LOOK SOMETHING UP USING IT!
>
> A "change ID" that I can't use to look anything up with is completely
> pointless and should be removed from kernel history.
>
> But if you have something unique that is actually useful for looking
> things up, then by all means. But it needs to be useful for
> _everybody_.

I presumably wasn't clear in my proposal.  My apologies and I will try
to be clearer.  I am proposing this:

1. I post v1 of my patch series to public mailing lists, like LKML.
Each patch in the series is tagged with a Change-Id which my own PC
made up.  I never touch a gerrit server anywhere.

2. I post v2 of my patch series to a public mailing list.  I make sure
that patches that are supposed to be newer versions of the same patch
in v1 contain the same Change-Id that they had in v1.  This is
something I already know how to do since sometimes I use gerrit and
that's how you work with gerrit.  I still haven't touched a single
gerrit server in this process.

3. The patch lands and still has the Change-Id.

Someone looking at the git history in the kernel can find the old
versions by searching public mailing lists for the Change-Id simply
using the standard ways to search mailing lists for a string.  There
is nothing excluding anyone here and it should be useful for everyone.

Someone doing a search of the mailing lists that finds patch v1 can
note the Change-Id and search the same mailing lists (and the kernel
history) for that Change-Id.  They can find it because the same string
was in v1 and v2.


> > * When a developer keeps the same Change-Id across two patches they
> > are making the assertion that the two patches are either the same or
> > should be treated as two versions of the same logical change.
>
> .. and we have better ways to do that.
>
> For example, we are actively encouraging things like message ID's
> (which are _also_ a form of locally generated UUID, they just are more
> than the silly purely numerical one).
>
> That gives you the origin of something, but it also gives you the
> development history and context.

I do not believe that there is any way to start with the Message-Id of
v2 of a patch and easily find v1 of the same patch.  Things like
cregit and email2git may have heuristics here, but I'm fairly certain
that they are not guaranteed to work.  I am happy to be corrected
here.  I can also spend time finding examples of cregit and email2git
failing if needed.


> But note that how when it comes to message ID's we encourage them in a
> form that actually also helps look that information up, ie the
> preferred form isn't just the message ID (although that exists), it's
> a link like
>
>     Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org
>
> instead of
>
>    Message-ID: 20190723065733.4899-5-leon@kernel.org
>
> even though technically they have just as much actual information in theory.

At the moment there is a chicken-and-egg problem.  We can't create
such a tool until Change-Id is there and Change-Id can't be there till
there is a tool.  However, I guess that could be solved by convincing
someone to create a tool that would return a list of emails that match
a given string.  Presumably such a tool would need to be hosted on
kernel.org.

NOTE: part of the usefulness of Change-Id is that it could be parsed
by a machine so that tools such as patchwork, gerrit, or other
not-yet-invented tools can always find the Change-Id.  If we were to
post it as a URL, I would want to make sure that everyone always used
the same URL.

I would further note that when you do "git log" each change is listed
with a random number (the git hash), not:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=59c36bc8d377c8764eb617a92211e0fc2f1318da

...so there is at least one precedent where people accept having an
ID, not a clickable URL.


> > At the moment, Change-Ids are highly associated in people's minds with
> > gerrit and many upstream developers dislike gerrit.
>
> No. That's not it at all. It's not "dislike gerrit".
>
> It's "dislike pointless garbage".
>
> If the gerrit database is public and searchable using the uuid, then
> that would make the uuid useful to outsiders. And instead of just
> putting a UUID (which is hard to look up unless you know where it came
> from), make it be that "Link:" that gives not just the UUID, but also
> gives you the metadata for that UUID to be looked up.
>
> But so far, in every single case the uuid's I've ever seen have been
> pointless garbage, that aren't useful in general to public open source
> developers, and as such shouldn't be in the git tree.
>
> See the difference?
>
> So if you guys make the gerrit database actually public, and then
> start adding "Link: ..." tags so that we can see what they point to, I
> think people will be more than supportive of it.
>
> But if it's some stupid and pointless UUID that is useful to nobody
> outside of google (or special magical groups of people associated with
> it), then I will personally continue to be very much against it.
>
> If it's some internal database for your exclusive club, then you can
> just have your own internal database to look that UUID up using a
> commit ID (or a patch ID that is generated from the patch), and you
> don't need to pollute the public with non-public noise.
>
> Do people do that "pointless pullution" thing? Yes, I've seen various
> companies add their garbage to the commit logs. Sometimes it makes it
> through. But if I see an email with random noise in it, I will
> personally remove that random useless noise.
>
> This is part of what "open source" is all about. There aren't supposed
> to be special people with access to inside information that get
> preferential treatment. If you have your private stuff, then fine, but
> keep it private. It has no business being in the public tree.

So I'm hoping that I addressed this above in saying that the Change-Id
I'm talking about has nothing to do with any gerrit server.  The
database is public because it is the existing mailing list archive.
Any use of the same Change-Id on an internal gerrit server is
meaningless in the context of my proposal.

-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  1:05         ` Olof Johansson
@ 2019-08-23  1:09           ` Dmitry Torokhov
  0 siblings, 0 replies; 105+ messages in thread
From: Dmitry Torokhov @ 2019-08-23  1:09 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	Dmitry Vyukov, David Rientjes, Dmitry Torokhov

On Thu, Aug 22, 2019 at 06:05:29PM -0700, Olof Johansson wrote:
> On Thu, Aug 22, 2019 at 5:45 PM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Thu, Aug 22, 2019 at 5:43 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On 8/22/19 5:30 PM, Olof Johansson wrote:
> > > > On Thu, Aug 22, 2019 at 5:17 PM Linus Torvalds
> > > > <torvalds@linux-foundation.org> wrote:
> > > >>
> > > >> On Thu, Aug 22, 2019 at 4:40 PM Doug Anderson <dianders@chromium.org> wrote:
> > > >>>
> > > >>> The Linux kernel has always viewed these Change-Id tags as obnoxious
> > > >>> and useless spam.  Anyone who accidentally leaves a Change-Id in their
> > > >>> patch when posting to the mailing list is told to please re-post their
> > > >>> patch without the Change-Id.  In this email, I will attempt to argue
> > > >>> that the Linux kernel ought to relax this restriction and allow
> > > >>> (possibly even encourage) Change-Ids.
> > > >>
> > > >> No.
> > > >>
> > > >> Not without some ground rules.
> > > >>
> > > >>> To begin with, let me make sure we're on the same page about what
> > > >>> Change-Ids are.  As I understand it:
> > > >>>
> > > >>> * A change ID is much alike a UUID.  It is locally generated on a
> > > >>> developer's computer and is (in theory) unique across the universe.
> > > >>
> > > >> Completely irrelevant.
> > > >>
> > > >> The point of an UUID is not just that it's unique, but THAT YOU CAN
> > > >> LOOK SOMETHING UP USING IT!
> > > >>
> > > >> A "change ID" that I can't use to look anything up with is completely
> > > >> pointless and should be removed from kernel history.
> > > >>
> > > >> But if you have something unique that is actually useful for looking
> > > >> things up, then by all means. But it needs to be useful for
> > > >> _everybody_.
> > > >>
> > > >>> * When a developer keeps the same Change-Id across two patches they
> > > >>> are making the assertion that the two patches are either the same or
> > > >>> should be treated as two versions of the same logical change.
> > > >>
> > > >> .. and we have better ways to do that.
> > > >>
> > > >> For example, we are actively encouraging things like message ID's
> > > >> (which are _also_ a form of locally generated UUID, they just are more
> > > >> than the silly purely numerical one).
> > > >>
> > > >> That gives you the origin of something, but it also gives you the
> > > >> development history and context.
> > > >>
> > > >> But note that how when it comes to message ID's we encourage them in a
> > > >> form that actually also helps look that information up, ie the
> > > >> preferred form isn't just the message ID (although that exists), it's
> > > >> a link like
> > > >>
> > > >>      Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org
> > > >>
> > > >> instead of
> > > >>
> > > >>     Message-ID: 20190723065733.4899-5-leon@kernel.org
> > > >>
> > > >> even though technically they have just as much actual information in theory.
> > > >>
> > > >> Do you see people complaining about that kind of UUID? No.  Because it
> > > >> gives useful information to the project, and when something happens,
> > > >> people can look things up and _use_ that kind of UUID.
> > > >
> > > > For the actual open projects, the answer to this might be relative
> > > > easy: Most gerrit instances can feed a mailing list with emails of
> > > > both the initial patch, and later comments.
> > > >
> > > > Said emails would obviously have a Message-ID, and if the list is
> > > > added to lore, it can be referenced there.
> > > >
> > > > Note, even if the Change-Id had a full URL, there would be no archival
> > > > guarantee in the same way as lore gives us, so that approach alone
> > > > isn't useful. A URL to a "forever" mailing list archive seems like the
> > > > most stable possible reference.
> > > >
> > > > This doesn't address the full issue Doug was looking to solve, which
> > > > is the reverse mapping of "posted patch" to "previous version of the
> > > > patch". Patchwork tries to guess this, but it's best effort. I don't
> > > > have a great answer to this, besides possibly in-reply-to threading
> > > > and associating back that way via the email trail.
> > > >
> > >
> > > Wouldn't a direct link to the Gerrit instance solve the problem ?
> > > After all,
> > >
> > > Link: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1759334
> > >
> > > points to the same Gerrit entry as
> > >
> > > Change-Id: I5a2e33424e7fb19fed13afb854ae6546ef9bfa35
> > >
> > > and there would be no need to look anything up.
> >
> > Nope, for the same reason I already mentioned: In 2 years when Google
> > deprecates Chromium and EOL's the product and project (see: Reader,
> > Google+, Youtube messaging), there will be no way to get to the
> > history. (I know, unlikely in this case, but URLs move without
> > redirects, etc).
> >
> > Lore solves that, since it's externally archived.
> 
> Actually, it seems like the outgoing email already has suitable headers.
> 
> I looked up a random review, and viewed raw message:
> 
> https://groups.google.com/a/chromium.org/forum/#!original/chromium-os-reviews/Y2R_LLKytQw/M0TRRzfoAgAJ
> 
> X-Gerrit-Change-Id: I50d72612569743198825afdf41200c15db759076
> X-Gerrit-Change-Number: 1762035
> X-Gerrit-ChangeURL:
> <https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1762035>
> X-Gerrit-Commit: 5b7dff2b2cb0b1a8769a53d59e387772ae569243
> 
> Since that would be captured in a mail archive, you could easily get
> it from there if needed.
> 
> Based on this, there's no reason to use opaque Change-Id, all the
> functionality needed can be reached through the mail URLs we already
> agreed are reasonable to use.
> 
> 
> (Someone should maybe tell Hao that he has the email address
> misspelled in his S-o-b).

This is however Gerrit-specific and I do not believe that Doug is
proposing to tie it all to Gerrit. I should be able to stick Change-Id
or tag we settle upon onto my outgoing patches and have it there without
any Gerrit involvement.

Thanks.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  1:07   ` Doug Anderson
@ 2019-08-23  1:18     ` Joel Fernandes
  0 siblings, 0 replies; 105+ messages in thread
From: Joel Fernandes @ 2019-08-23  1:18 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Barret Rhoden, Dmitry Torokhov, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	Dmitry Vyukov, David Rientjes

On Thu, Aug 22, 2019 at 9:07 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Thu, Aug 22, 2019 at 5:17 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > > To begin with, let me make sure we're on the same page about what
> > > Change-Ids are.  As I understand it:
> > >
> > > * A change ID is much alike a UUID.  It is locally generated on a
> > > developer's computer and is (in theory) unique across the universe.
> >
> > Completely irrelevant.
> >
> > The point of an UUID is not just that it's unique, but THAT YOU CAN
> > LOOK SOMETHING UP USING IT!
> >
> > A "change ID" that I can't use to look anything up with is completely
> > pointless and should be removed from kernel history.
> >
> > But if you have something unique that is actually useful for looking
> > things up, then by all means. But it needs to be useful for
> > _everybody_.
>
> I presumably wasn't clear in my proposal.  My apologies and I will try
> to be clearer.  I am proposing this:
>
> 1. I post v1 of my patch series to public mailing lists, like LKML.
> Each patch in the series is tagged with a Change-Id which my own PC
> made up.  I never touch a gerrit server anywhere.
>
> 2. I post v2 of my patch series to a public mailing list.  I make sure
> that patches that are supposed to be newer versions of the same patch
> in v1 contain the same Change-Id that they had in v1.  This is
> something I already know how to do since sometimes I use gerrit and
> that's how you work with gerrit.  I still haven't touched a single
> gerrit server in this process.
>
> 3. The patch lands and still has the Change-Id.
>
> Someone looking at the git history in the kernel can find the old
> versions by searching public mailing lists for the Change-Id simply
> using the standard ways to search mailing lists for a string.  There
> is nothing excluding anyone here and it should be useful for everyone.
>
> Someone doing a search of the mailing lists that finds patch v1 can
> note the Change-Id and search the same mailing lists (and the kernel
> history) for that Change-Id.  They can find it because the same string
> was in v1 and v2.
>
>
> > > * When a developer keeps the same Change-Id across two patches they
> > > are making the assertion that the two patches are either the same or
> > > should be treated as two versions of the same logical change.
> >
> > .. and we have better ways to do that.
> >
> > For example, we are actively encouraging things like message ID's
> > (which are _also_ a form of locally generated UUID, they just are more
> > than the silly purely numerical one).
> >
> > That gives you the origin of something, but it also gives you the
> > development history and context.
>
> I do not believe that there is any way to start with the Message-Id of
> v2 of a patch and easily find v1 of the same patch.  Things like
> cregit and email2git may have heuristics here, but I'm fairly certain
> that they are not guaranteed to work.  I am happy to be corrected
> here.  I can also spend time finding examples of cregit and email2git
> failing if needed.

Could email2git be made more robust - if each revision of a patch
contained a Message-id of the previous revision(s), then it strings
them together? A list post already has a Message-Id to uniquely
identify it.

Also Message-Id is more flexible, it can be used to refer to other
patches or other discussions which may not necessarily refer to older
patch revisions.

I see your point, but IMO - I don't think it is practical to force all
Linux contributors to use a new Change-Id and expect that they will
stick to using it. It is better to use existing tools.

thanks,

 - Joel
[snip]

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  0:45       ` Olof Johansson
  2019-08-23  1:05         ` Olof Johansson
@ 2019-08-23  1:36         ` Theodore Y. Ts'o
  2019-08-23  2:58           ` Linus Torvalds
  1 sibling, 1 reply; 105+ messages in thread
From: Theodore Y. Ts'o @ 2019-08-23  1:36 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	Dmitry Vyukov, David Rientjes, Dmitry Torokhov

On Thu, Aug 22, 2019 at 05:45:59PM -0700, Olof Johansson wrote:
> 
> Nope, for the same reason I already mentioned: In 2 years when Google
> deprecates Chromium and EOL's the product and project (see: Reader,
> Google+, Youtube messaging), there will be no way to get to the
> history. (I know, unlikely in this case, but URLs move without
> redirects, etc).

That concern applies to URL's.  Red Hat could get shut down by IBM, at
which point all of the links to bugzilla.redhat.com could go away.
Yeah, unlikely, but so is chromium.gerrit.com going away.  We never
requested a commitment from Red Hat that bugzilla.redhat.com would go
away before we allowed Red Hat bugzilla links in git descriptions.
Ditto for launchpad.net, etc.  In fact, I'd argue that launchpad is
even more likely to disappear given that it's all subject to the whims
of Mark Shuttleworth.  :-)

Ditto links to patchwork.freedesktop.org, patchwork.ozlabs.org, etc.

Surely it's obvious that:

Link: https://linux-review.googlesource.com/c/1158

is more useful than:

Change-Id: I3268f9036512c4378cde1da37e0612b43ed4d384

And given that we're not disallowing other Link: trailers, it seems to
be purely an anti-Gerrit bias which is causing people to say, "Nein!"
for links into Gerrit servers as opposed to Bugzilla or Patchwork
servers.

					- Ted

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  1:36         ` Theodore Y. Ts'o
@ 2019-08-23  2:58           ` Linus Torvalds
  2019-08-23  3:03             ` Linus Torvalds
  2019-08-23  9:09             ` Vlastimil Babka
  0 siblings, 2 replies; 105+ messages in thread
From: Linus Torvalds @ 2019-08-23  2:58 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Thu, Aug 22, 2019 at 6:36 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> Surely it's obvious that:
>
> Link: https://linux-review.googlesource.com/c/1158
>
> is more useful than:
>
> Change-Id: I3268f9036512c4378cde1da37e0612b43ed4d384

Yes, I think that just using the link when you have a public-facing
gerrit database is perfectly fine already today, and people could
start using it.

Might that link some day die? Sure. That's fundamental to any external
link. I don't think it's all that productive to then argue whose links
are more likely to die before some other link, unless it looks like
some project is actively trying to game the system and has a pattern
of having links that are active only for a short while after the
commit has gone public.

And I don't see much point to doing that.

So yes, I'd *much* rather see that "Link" line than try to make a
"Change-ID" line be a thing.

Of course, looking at that particular link, my initial reaction is
"people are bad spellers". The word 'amend' has a single 'm' ;)

And it _is_ important that the link in question is stable, of course.
Some systems have problems with that. Is that "c/1158" actually a
stable long-lived name that will stay around as the thing is modified?
I don't know how that system works.

           Linus

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  2:58           ` Linus Torvalds
@ 2019-08-23  3:03             ` Linus Torvalds
  2019-08-23 13:15               ` Sean Paul
                                 ` (2 more replies)
  2019-08-23  9:09             ` Vlastimil Babka
  1 sibling, 3 replies; 105+ messages in thread
From: Linus Torvalds @ 2019-08-23  3:03 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Thu, Aug 22, 2019 at 7:58 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So yes, I'd *much* rather see that "Link" line than try to make a
> "Change-ID" line be a thing.

Tangential note: since it looks like "Link:" lines are going to get
more common in general, maybe somebody with the right tck/tk-fu can
make a tool like 'gitk' be able to just do the hyperlinking thing (it
already does it for commit hashes in the commit message, but wouldn't
it be convenient to do that for web links too and open a browser
tab?).

And maybe we can even make git.kernel.org do it too (I think that uses cgit?).

I think that might make it just nicer in general to browse the logs
and actually follow the links without cut-and-paste games..

So using a generic "Link:" tag that can be used for multiple different
things sounds like a win in general over some specialized change-ID
tag. No?

              Linus

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  2:58           ` Linus Torvalds
  2019-08-23  3:03             ` Linus Torvalds
@ 2019-08-23  9:09             ` Vlastimil Babka
  2019-08-23 12:48               ` Bhaskar Chowdhury
  1 sibling, 1 reply; 105+ messages in thread
From: Vlastimil Babka @ 2019-08-23  9:09 UTC (permalink / raw)
  To: Linus Torvalds, Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On 8/23/19 4:58 AM, Linus Torvalds wrote:
> So yes, I'd *much* rather see that "Link" line than try to make a
> "Change-ID" line be a thing.
> 
> Of course, looking at that particular link, my initial reaction is
> "people are bad spellers". The word 'amend' has a single 'm' ;)
> 
> And it _is_ important that the link in question is stable, of course.
> Some systems have problems with that. Is that "c/1158" actually a
> stable long-lived name that will stay around as the thing is modified?
> I don't know how that system works.

Looks like there are also links that include the change-id, and redirect
to the shorter one, i.e.
https://linux-review.googlesource.com/q/I3268f9036512c4378cde1da37e0612b43ed4d384

Seems to me like that's "the best of both worlds" - a link you can
click, and also a unique ID that can perhaps outlive the particular
website and you can search for it elsewhere in the future, if there are
other mirrors. Exactly like the message id's in links to lore.kernel.org.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  9:09             ` Vlastimil Babka
@ 2019-08-23 12:48               ` Bhaskar Chowdhury
  0 siblings, 0 replies; 105+ messages in thread
From: Bhaskar Chowdhury @ 2019-08-23 12:48 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: Joel Fernandes, Barret Rhoden, Dmitry Torokhov, ksummit,
	Greg Kroah-Hartman, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Vyukov

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

Clicking on the Change-Id doesn't have any effect or do I miss the
feature completely?? It open up in similar window in another tab...not
sure that is what required. I mean what's the point of having redundent
window open in two different browser tab??

Wondering!!

~Bhaskar

On 11:09 Fri 23 Aug 2019, Vlastimil Babka wrote:
>On 8/23/19 4:58 AM, Linus Torvalds wrote:
>> So yes, I'd *much* rather see that "Link" line than try to make a
>> "Change-ID" line be a thing.
>>
>> Of course, looking at that particular link, my initial reaction is
>> "people are bad spellers". The word 'amend' has a single 'm' ;)
>>
>> And it _is_ important that the link in question is stable, of course.
>> Some systems have problems with that. Is that "c/1158" actually a
>> stable long-lived name that will stay around as the thing is modified?
>> I don't know how that system works.
>
>Looks like there are also links that include the change-id, and redirect
>to the shorter one, i.e.
>https://linux-review.googlesource.com/q/I3268f9036512c4378cde1da37e0612b43ed4d384
>
>Seems to me like that's "the best of both worlds" - a link you can
>click, and also a unique ID that can perhaps outlive the particular
>website and you can search for it elsewhere in the future, if there are
>other mirrors. Exactly like the message id's in links to lore.kernel.org.
>_______________________________________________
>Ksummit-discuss mailing list
>Ksummit-discuss@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  3:03             ` Linus Torvalds
@ 2019-08-23 13:15               ` Sean Paul
  2019-08-23 15:18                 ` Theodore Y. Ts'o
  2019-08-23 18:10               ` Konstantin Ryabitsev
  2019-08-26 22:19               ` Paul Mackerras
  2 siblings, 1 reply; 105+ messages in thread
From: Sean Paul @ 2019-08-23 13:15 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Thu, Aug 22, 2019 at 11:04 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Thu, Aug 22, 2019 at 7:58 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So yes, I'd *much* rather see that "Link" line than try to make a
> > "Change-ID" line be a thing.
>
> Tangential note: since it looks like "Link:" lines are going to get
> more common in general, maybe somebody with the right tck/tk-fu can
> make a tool like 'gitk' be able to just do the hyperlinking thing (it
> already does it for commit hashes in the commit message, but wouldn't
> it be convenient to do that for web links too and open a browser
> tab?).
>
> And maybe we can even make git.kernel.org do it too (I think that uses cgit?).
>
> I think that might make it just nicer in general to browse the logs
> and actually follow the links without cut-and-paste games..
>
> So using a generic "Link:" tag that can be used for multiple different
> things sounds like a win in general over some specialized change-ID
> tag. No?

Only if you've uploaded the patch somewhere before sending it to the
mailing list. I think this would satisfy the Gerrit crowd, since
they're presumably uploading the patch to Gerrit, getting some review
on it and then sending it upstream. They will have a link. If you're
just interested in being archival tool friendly, you probably just
want to add some uuid cookie to the patch and post it directly to the
mailing list.

That said, I don't think Change-Id (or Uuid or whatever the cookie tag
is named) needs to be committed to git. If people stuck their
Change-Id tag below '---' in their mail, it would solve the issue of
finding old revisions on the list. This would also allow tooling (like
patchwork) to track across revisions. It's pretty easy to work
backwards from a commit to _any_ one revision of the patch on the m-l,
and that will give you the Change-Id.

If Change-Id becomes widely useful below '---', you could add support
in patchwork to allow direct linking by Change-Id. This would allow
people to add Link: <patchwork-server/change-id/<change-id> to their
commit messages without first uploading it somewhere.

Sean

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 13:15               ` Sean Paul
@ 2019-08-23 15:18                 ` Theodore Y. Ts'o
  2019-08-23 15:31                   ` Sean Paul
  0 siblings, 1 reply; 105+ messages in thread
From: Theodore Y. Ts'o @ 2019-08-23 15:18 UTC (permalink / raw)
  To: Sean Paul
  Cc: Joel Fernandes, Barret Rhoden, Dmitry Torokhov, ksummit,
	Greg Kroah-Hartman, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Vyukov

On Fri, Aug 23, 2019 at 09:15:30AM -0400, Sean Paul wrote:
> Only if you've uploaded the patch somewhere before sending it to the
> mailing list. I think this would satisfy the Gerrit crowd, since
> they're presumably uploading the patch to Gerrit, getting some review
> on it and then sending it upstream. They will have a link. If you're
> just interested in being archival tool friendly, you probably just
> want to add some uuid cookie to the patch and post it directly to the
> mailing list.

And this is why I think something like one of the two:

Link: https://linux-review.googlesource.com/c/1158
Link: https://linux-review.googlesource.com/q/I3268f9036512c4378cde1da37e0612b43ed4d384

... is a better choice.

The Link tag, unlike the Change-Id: hidden amongst the diffstat,
allows any patch review comments which are made via Gerrit to be
accessible to the public.  The main reason why I suggested the first
as opposed to the second initially is that one of the pushbacks
against the "Change-Id: " header was that the
"I3268f9036512c4378cde1da37e0612b43ed4d384" portion was ugly.

Yes, that's purely an aesthetics argument, but in terms of human
emotional acceptance, that's important.  The first is arguably better
than:

Link: https://bugzilla.kernel.org/show_bug.cgi?id=200847

... which people are already willing to accept.

There are some advantages to the second, in that we don't have to
contact Gerrit to assign the small integer number.  Either way,
though, it should easy to teach Gerrit how to interpret either instead
of the "Change-Id:" tag, and for publically accessible Gerrit
instances, the Link: tag is strictly superior.  It allows you to know
which Gerrit server to contact to find the review history, and it
becomes obvious whether that Gerrit server is publicaly accessible, or
if it is hidden behind a corporate firewall.

Cheers,

					- Ted

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 15:18                 ` Theodore Y. Ts'o
@ 2019-08-23 15:31                   ` Sean Paul
  2019-08-23 15:48                     ` Thomas Gleixner
  2019-08-23 15:49                     ` Doug Anderson
  0 siblings, 2 replies; 105+ messages in thread
From: Sean Paul @ 2019-08-23 15:31 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, Dmitry Torokhov, ksummit,
	Greg Kroah-Hartman, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Vyukov

On Fri, Aug 23, 2019 at 11:18 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Fri, Aug 23, 2019 at 09:15:30AM -0400, Sean Paul wrote:
> > Only if you've uploaded the patch somewhere before sending it to the
> > mailing list. I think this would satisfy the Gerrit crowd, since
> > they're presumably uploading the patch to Gerrit, getting some review
> > on it and then sending it upstream. They will have a link. If you're
> > just interested in being archival tool friendly, you probably just
> > want to add some uuid cookie to the patch and post it directly to the
> > mailing list.
>
> And this is why I think something like one of the two:
>
> Link: https://linux-review.googlesource.com/c/1158
> Link: https://linux-review.googlesource.com/q/I3268f9036512c4378cde1da37e0612b43ed4d384
>
> ... is a better choice.
>

Agreed. If you have a url for the patch this makes sense.

I don't upload my patches to Gerrit, but I am interested in enabling
patchwork (or equivalent tool) to do a better job of tracking revision
changes.

Currently I just link to all past revisions in the latest one (see
[1]) so folks can see the prior discussion. It'd be nice if there was
an easier way of achieving this.

Sean

[1]- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1452c25b0e60278820f3d2155c65f1bfcce5ee79



> The Link tag, unlike the Change-Id: hidden amongst the diffstat,
> allows any patch review comments which are made via Gerrit to be
> accessible to the public.  The main reason why I suggested the first
> as opposed to the second initially is that one of the pushbacks
> against the "Change-Id: " header was that the
> "I3268f9036512c4378cde1da37e0612b43ed4d384" portion was ugly.
>
> Yes, that's purely an aesthetics argument, but in terms of human
> emotional acceptance, that's important.  The first is arguably better
> than:
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=200847
>
> ... which people are already willing to accept.
>
> There are some advantages to the second, in that we don't have to
> contact Gerrit to assign the small integer number.  Either way,
> though, it should easy to teach Gerrit how to interpret either instead
> of the "Change-Id:" tag, and for publically accessible Gerrit
> instances, the Link: tag is strictly superior.  It allows you to know
> which Gerrit server to contact to find the review history, and it
> becomes obvious whether that Gerrit server is publicaly accessible, or
> if it is hidden behind a corporate firewall.
>
> Cheers,
>
>                                         - Ted

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 15:31                   ` Sean Paul
@ 2019-08-23 15:48                     ` Thomas Gleixner
  2019-08-23 16:19                       ` Dmitry Torokhov
  2019-08-23 15:49                     ` Doug Anderson
  1 sibling, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-23 15:48 UTC (permalink / raw)
  To: Sean Paul
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Fri, 23 Aug 2019, Sean Paul wrote:
> On Fri, Aug 23, 2019 at 11:18 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> >
> > On Fri, Aug 23, 2019 at 09:15:30AM -0400, Sean Paul wrote:
> > > Only if you've uploaded the patch somewhere before sending it to the
> > > mailing list. I think this would satisfy the Gerrit crowd, since
> > > they're presumably uploading the patch to Gerrit, getting some review
> > > on it and then sending it upstream. They will have a link. If you're
> > > just interested in being archival tool friendly, you probably just
> > > want to add some uuid cookie to the patch and post it directly to the
> > > mailing list.
> >
> > And this is why I think something like one of the two:
> >
> > Link: https://linux-review.googlesource.com/c/1158
> > Link: https://linux-review.googlesource.com/q/I3268f9036512c4378cde1da37e0612b43ed4d384
> >
> > ... is a better choice.
> >
> 
> Agreed. If you have a url for the patch this makes sense.
> 
> I don't upload my patches to Gerrit, but I am interested in enabling
> patchwork (or equivalent tool) to do a better job of tracking revision
> changes.
> 
> Currently I just link to all past revisions in the latest one (see
> [1]) so folks can see the prior discussion. It'd be nice if there was
> an easier way of achieving this.

That's mostly a question of being careful about it. The initial submissions
cover letter starts the whole thing. For any following version, the cover
letter should have:

    This is version X of this series. The previous version can be found
    here:

	https://lkml.kernel.org/r/$MSGID_PREV_COVERLETTER

So when the final version gets applied, then each commit gets a link:

   Link: https://lkml.kernel.org/r/$MSGID_OF_PATCH_$N

Then it's just a matter of following the links and that can be automated.

For a single patch w/o cover letter this can be solved as well:

    Subject ....

    changelog

    SOB
    ---
    V3: Fixed stuff
    V2: https://lkml.kernel.org/r/$MSGID_OF_PATCH_V2

    diffstat
    ---
    diff

And looking at the above example, you can add even gerrit ids or whatever
information into the '---' discard section. It's going to be in the mail
archive and traceable by the commit Link.

Yes, it's work for the submitter, but it's always work if the submitter
wants to have a proper trace.

For the committer it's a matter of tooling to add the link with the message
id per patch. I'm doing that for years fully automated.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 15:31                   ` Sean Paul
  2019-08-23 15:48                     ` Thomas Gleixner
@ 2019-08-23 15:49                     ` Doug Anderson
  2019-08-23 15:54                       ` Thomas Gleixner
  1 sibling, 1 reply; 105+ messages in thread
From: Doug Anderson @ 2019-08-23 15:49 UTC (permalink / raw)
  To: Sean Paul
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi,

On Fri, Aug 23, 2019 at 8:31 AM Sean Paul <seanpaul@chromium.org> wrote:
>
> On Fri, Aug 23, 2019 at 11:18 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> >
> > On Fri, Aug 23, 2019 at 09:15:30AM -0400, Sean Paul wrote:
> > > Only if you've uploaded the patch somewhere before sending it to the
> > > mailing list. I think this would satisfy the Gerrit crowd, since
> > > they're presumably uploading the patch to Gerrit, getting some review
> > > on it and then sending it upstream. They will have a link. If you're
> > > just interested in being archival tool friendly, you probably just
> > > want to add some uuid cookie to the patch and post it directly to the
> > > mailing list.
> >
> > And this is why I think something like one of the two:
> >
> > Link: https://linux-review.googlesource.com/c/1158
> > Link: https://linux-review.googlesource.com/q/I3268f9036512c4378cde1da37e0612b43ed4d384
> >
> > ... is a better choice.
> >
>
> Agreed. If you have a url for the patch this makes sense.
>
> I don't upload my patches to Gerrit, but I am interested in enabling
> patchwork (or equivalent tool) to do a better job of tracking revision
> changes.

Right.  I think the point that I've been trying to make is that just
like Sean: I have no gerrit server involved when I submit patches to
the list.  I do:

1. Write patch on my local machine.
2. Post v1 to mailing list.
3. Make changes.
4. Post v2 to mailing list.
5. Make changes.
5. Post v3 to mailing list.

I have never uploaded to a gerrit in this process.  THERE IS NO GERRIT
LINK!  Yet, just like Sean Paul says, I would like patchwork (or any
other system trawling through the mailing lists) to link my v1 to my
v2 to my v3.

The key here is that Change-Id needs to be consumed by machines.  Yes,
it's nice if humans can also find it useful by itself, but primarily
we need programs (like patchwork) to be able to understand it and link
v1 to v2 to v3.  Unless the link is in a super structured Canonical
form then it is WORSE for a machine to consume than just a plain
Change-Id.

Personally I'd rather keep Change-Id as-is with no link because it
means that those who already have a workflow can keep using it and
just stop stripping Change-Id.  However, if people really want a link
we can make one up.  Remember, though, that at the time of posting v1
that link points to NOWHERE.  THERE IS NO SERVER.  Thus you are
speculating that (presumably) that link will find the patch you posted
because you know that the list will be scraped by a bot.

NOTE: I suppose I could do this today:

https://lore.kernel.org/lkml/?q=Change-Id%3A+I23e218cd964f16c0b2b26127d4a5ca6529867673

...and it would work.  Ironically Mark yelled about that not providing
any use outside of the company's system, but I just effectively used
it to find v1 and v2 of the patch and also link it to what landed in
the kernel tree (where, apparently, Mark missed stripping the
Change-Id).  ...and the "discussion" about the patch.


-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 15:49                     ` Doug Anderson
@ 2019-08-23 15:54                       ` Thomas Gleixner
  2019-08-23 15:59                         ` Thomas Gleixner
  0 siblings, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-23 15:54 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Fri, 23 Aug 2019, Doug Anderson wrote:
> On Fri, Aug 23, 2019 at 8:31 AM Sean Paul <seanpaul@chromium.org> wrote:
> Personally I'd rather keep Change-Id as-is with no link because it
> means that those who already have a workflow can keep using it and
> just stop stripping Change-Id.  However, if people really want a link
> we can make one up.  Remember, though, that at the time of posting v1
> that link points to NOWHERE.  THERE IS NO SERVER.  Thus you are
> speculating that (presumably) that link will find the patch you posted
> because you know that the list will be scraped by a bot.
> 
> NOTE: I suppose I could do this today:
> 
> https://lore.kernel.org/lkml/?q=Change-Id%3A+I23e218cd964f16c0b2b26127d4a5ca6529867673
> 
> ...and it would work.  Ironically Mark yelled about that not providing
> any use outside of the company's system, but I just effectively used
> it to find v1 and v2 of the patch and also link it to what landed in
> the kernel tree (where, apparently, Mark missed stripping the
> Change-Id).  ...and the "discussion" about the patch.

As I said to Sean:

   Put the change id into the discard section of your patch mail or into
   the cover letter. So it's in the archive and if we really can agree on
   having the

   	  Link://lkml.kernel.org/r/$MSGID_PER_PATCH

   in the actual commit, then Linus is happy and you have your gerrit ID
   via a mouse click or just via that search you have above.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 15:54                       ` Thomas Gleixner
@ 2019-08-23 15:59                         ` Thomas Gleixner
  2019-08-23 16:38                           ` Doug Anderson
  0 siblings, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-23 15:59 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Fri, 23 Aug 2019, Thomas Gleixner wrote:
> On Fri, 23 Aug 2019, Doug Anderson wrote:
> > On Fri, Aug 23, 2019 at 8:31 AM Sean Paul <seanpaul@chromium.org> wrote:
> > Personally I'd rather keep Change-Id as-is with no link because it
> > means that those who already have a workflow can keep using it and
> > just stop stripping Change-Id.  However, if people really want a link
> > we can make one up.  Remember, though, that at the time of posting v1
> > that link points to NOWHERE.  THERE IS NO SERVER.  Thus you are
> > speculating that (presumably) that link will find the patch you posted
> > because you know that the list will be scraped by a bot.
> > 
> > NOTE: I suppose I could do this today:
> > 
> > https://lore.kernel.org/lkml/?q=Change-Id%3A+I23e218cd964f16c0b2b26127d4a5ca6529867673
> > 
> > ...and it would work.  Ironically Mark yelled about that not providing
> > any use outside of the company's system, but I just effectively used
> > it to find v1 and v2 of the patch and also link it to what landed in
> > the kernel tree (where, apparently, Mark missed stripping the
> > Change-Id).  ...and the "discussion" about the patch.
> 
> As I said to Sean:
> 
>    Put the change id into the discard section of your patch mail or into
>    the cover letter. So it's in the archive and if we really can agree on
>    having the
> 
>    	  Link://lkml.kernel.org/r/$MSGID_PER_PATCH
> 
>    in the actual commit, then Linus is happy and you have your gerrit ID
>    via a mouse click or just via that search you have above.

And that avoids also the discussion about public/private references as
neither the cover letter nor the discard section are part of the actual
commit message.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 15:48                     ` Thomas Gleixner
@ 2019-08-23 16:19                       ` Dmitry Torokhov
  2019-08-23 16:35                         ` Joel Fernandes
  0 siblings, 1 reply; 105+ messages in thread
From: Dmitry Torokhov @ 2019-08-23 16:19 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi Thomas,

On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wrote:
> 
> Yes, it's work for the submitter, but it's always work if the submitter
> wants to have a proper trace.

Here is where I disagree with you. As a patch submitter, I frankly could
not care less about proper trace, history, etc. I might be putting cover
letter and outline the version changes, but I am doing that to reduce
friction and help committer to land my change. Thant's it. And
committers seem to have enough context from the provided version history
and memory of the previous iterations.

Who this new ID benefits most is a system integrator that is tracking
all bits and pieces that are needed for their board to boot and work
properly. Hopefully the system integrator is a good community citizen
and not only wants to apply patches locally, but also make sure
stragglers end up in mainline after all. But they need additional
history to know whether the series was just forgotten, a new solution
was adopted instead, and so on.

It also can help maintainers who need (maybe years later) to research
why particular change was made and whether there was additional
discussion around certain point of the change.

The process you outlined above (collecting msg ids from previous
submissions, putting them into cover letter, etc) adds too much friction
at submission time so that submitters will not actually do any of that.
However having a git hook adding an ID to any new commit is much more
workable.


Thanks.
 
-- 
Dmitry

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 16:19                       ` Dmitry Torokhov
@ 2019-08-23 16:35                         ` Joel Fernandes
  2019-08-23 16:45                           ` Doug Anderson
  2019-08-23 16:46                           ` Dmitry Torokhov
  0 siblings, 2 replies; 105+ messages in thread
From: Joel Fernandes @ 2019-08-23 16:35 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Thomas,
>
> On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wrote:
> >
> > Yes, it's work for the submitter, but it's always work if the submitter
> > wants to have a proper trace.
>
> Here is where I disagree with you. As a patch submitter, I frankly could
> not care less about proper trace, history, etc. I might be putting cover

But that is exactly what the problem statement is. Doug does care
about tracing/history and wants that to be more robust etc.

> letter and outline the version changes, but I am doing that to reduce
> friction and help committer to land my change. Thant's it. And
> committers seem to have enough context from the provided version history
> and memory of the previous iterations.
>
> Who this new ID benefits most is a system integrator that is tracking
> all bits and pieces that are needed for their board to boot and work
> properly. Hopefully the system integrator is a good community citizen
> and not only wants to apply patches locally, but also make sure
> stragglers end up in mainline after all. But they need additional
> history to know whether the series was just forgotten, a new solution
> was adopted instead, and so on.
>
> It also can help maintainers who need (maybe years later) to research
> why particular change was made and whether there was additional
> discussion around certain point of the change.
>
> The process you outlined above (collecting msg ids from previous
> submissions, putting them into cover letter, etc) adds too much friction
> at submission time so that submitters will not actually do any of that.
> However having a git hook adding an ID to any new commit is much more
> workable.

I don't think a git-hook will solve what Doug is asking. There is
always some need for manual labor to add the metadata pointing to
previous patch posting. How does anyone but the patch submitter know
what the link/id/whatever of the previous patch posting or series is?
Unless git has some telepathy abilities that I did not know about.

Since my day job involves gerrit usage, I have used gerrit and
whenever I have a brand new patch for something; I have had to
manually add the old Change-Id to the new change so that gerrit
recognizes that it is linked to the old patch. That process is not
done by a hook. Sure the initial generation is through a hook, but
still.

thanks,

 - Joel

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 15:59                         ` Thomas Gleixner
@ 2019-08-23 16:38                           ` Doug Anderson
  2019-08-23 16:50                             ` Andrew Lunn
  0 siblings, 1 reply; 105+ messages in thread
From: Doug Anderson @ 2019-08-23 16:38 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi,

On Fri, Aug 23, 2019 at 8:59 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Fri, 23 Aug 2019, Thomas Gleixner wrote:
> > On Fri, 23 Aug 2019, Doug Anderson wrote:
> > > On Fri, Aug 23, 2019 at 8:31 AM Sean Paul <seanpaul@chromium.org> wrote:
> > > Personally I'd rather keep Change-Id as-is with no link because it
> > > means that those who already have a workflow can keep using it and
> > > just stop stripping Change-Id.  However, if people really want a link
> > > we can make one up.  Remember, though, that at the time of posting v1
> > > that link points to NOWHERE.  THERE IS NO SERVER.  Thus you are
> > > speculating that (presumably) that link will find the patch you posted
> > > because you know that the list will be scraped by a bot.
> > >
> > > NOTE: I suppose I could do this today:
> > >
> > > https://lore.kernel.org/lkml/?q=Change-Id%3A+I23e218cd964f16c0b2b26127d4a5ca6529867673
> > >
> > > ...and it would work.  Ironically Mark yelled about that not providing
> > > any use outside of the company's system, but I just effectively used
> > > it to find v1 and v2 of the patch and also link it to what landed in
> > > the kernel tree (where, apparently, Mark missed stripping the
> > > Change-Id).  ...and the "discussion" about the patch.
> >
> > As I said to Sean:
> >
> >    Put the change id into the discard section of your patch mail or into
> >    the cover letter. So it's in the archive and if we really can agree on
> >    having the
> >
> >         Link://lkml.kernel.org/r/$MSGID_PER_PATCH
> >
> >    in the actual commit, then Linus is happy and you have your gerrit ID
> >    via a mouse click or just via that search you have above.
>
> And that avoids also the discussion about public/private references as
> neither the cover letter nor the discard section are part of the actual
> commit message.

If it is agreed upon to:

1. Make it allowed or suggested to put a well-formed (machine
parseable) Change-Id "after the cut" on mailing list posts, which
would allow you to associate v1, v2, and v3.

2. Add "Link://lkml.kernel.org/r/$MSGID_PER_PATCH" to landed patches,
which would allow you to recover the Change-Id even after a patch
lands.

...then I will be happy (ish).  The biggest downside I see here is
that it is much less likely that random committers out there will get
this right.  The way committers naturally have the same Change-Id from
v1 to v2 to v3 is because it's part of the commit message and when you
amend to a previous change it stays there.  That means that these
people will need to remember to move the Change-Id to "after the cut"
unless we teach git-send-email to do this for you (though I guess
maybe we could do that?).


-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 16:35                         ` Joel Fernandes
@ 2019-08-23 16:45                           ` Doug Anderson
  2019-08-23 16:54                             ` Joel Fernandes
  2019-08-23 16:46                           ` Dmitry Torokhov
  1 sibling, 1 reply; 105+ messages in thread
From: Doug Anderson @ 2019-08-23 16:45 UTC (permalink / raw)
  To: Joel Fernandes
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

Hi,

On Fri, Aug 23, 2019 at 9:35 AM Joel Fernandes via Ksummit-discuss
<ksummit-discuss@lists.linuxfoundation.org> wrote:
>
> On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > Hi Thomas,
> >
> > On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wrote:
> > >
> > > Yes, it's work for the submitter, but it's always work if the submitter
> > > wants to have a proper trace.
> >
> > Here is where I disagree with you. As a patch submitter, I frankly could
> > not care less about proper trace, history, etc. I might be putting cover
>
> But that is exactly what the problem statement is. Doug does care
> about tracing/history and wants that to be more robust etc.

Well, I care because I'm a system integrator, not because I'm a patch
submitter.  I try to make my patch submissions useful for system
integrators because I am also a system integrator.  ...but most patch
submitters don't try so hard.  We need to make this easy for them.


> > letter and outline the version changes, but I am doing that to reduce
> > friction and help committer to land my change. Thant's it. And
> > committers seem to have enough context from the provided version history
> > and memory of the previous iterations.
> >
> > Who this new ID benefits most is a system integrator that is tracking
> > all bits and pieces that are needed for their board to boot and work
> > properly. Hopefully the system integrator is a good community citizen
> > and not only wants to apply patches locally, but also make sure
> > stragglers end up in mainline after all. But they need additional
> > history to know whether the series was just forgotten, a new solution
> > was adopted instead, and so on.
> >
> > It also can help maintainers who need (maybe years later) to research
> > why particular change was made and whether there was additional
> > discussion around certain point of the change.
> >
> > The process you outlined above (collecting msg ids from previous
> > submissions, putting them into cover letter, etc) adds too much friction
> > at submission time so that submitters will not actually do any of that.
> > However having a git hook adding an ID to any new commit is much more
> > workable.
>
> I don't think a git-hook will solve what Doug is asking. There is
> always some need for manual labor to add the metadata pointing to
> previous patch posting. How does anyone but the patch submitter know
> what the link/id/whatever of the previous patch posting or series is?
> Unless git has some telepathy abilities that I did not know about.
>
> Since my day job involves gerrit usage, I have used gerrit and
> whenever I have a brand new patch for something; I have had to
> manually add the old Change-Id to the new change so that gerrit
> recognizes that it is linked to the old patch. That process is not
> done by a hook. Sure the initial generation is through a hook, but
> still.

You must have a different flow than I do.  For me the Change-Id just
naturally stays there as I make changes to the patch.  When I post
patches to an upstream list I keep them around as a local branch.
When changes are requested, I pick the old patches and amend to them.
...or I use "git rebase -i" and do a "FIXUP" to make changes to a
previous patch.  With this workflow the Change-Id is super low
friction and automatic.

...so for me the git-hook works perfectly well and the Change-Id just
naturally stays there in most cases.

Sure, if a given patch in the series is totally wrong and I re-write
it (but still want the re-write to be considered a new version of the
previous patch) then I have to manually copy the Change-Id for a
gerrit upload.  ...but I'd also be OK if people just get a new
Change-Id in this case.


-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 16:35                         ` Joel Fernandes
  2019-08-23 16:45                           ` Doug Anderson
@ 2019-08-23 16:46                           ` Dmitry Torokhov
  2019-08-23 19:17                             ` Thomas Gleixner
  1 sibling, 1 reply; 105+ messages in thread
From: Dmitry Torokhov @ 2019-08-23 16:46 UTC (permalink / raw)
  To: Joel Fernandes
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Fri, Aug 23, 2019 at 12:35:03PM -0400, Joel Fernandes wrote:
> On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > Hi Thomas,
> >
> > On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wrote:
> > >
> > > Yes, it's work for the submitter, but it's always work if the submitter
> > > wants to have a proper trace.
> >
> > Here is where I disagree with you. As a patch submitter, I frankly could
> > not care less about proper trace, history, etc. I might be putting cover
> 
> But that is exactly what the problem statement is. Doug does care
> about tracing/history and wants that to be more robust etc.

Doug here is not a submitter ;)

> 
> > letter and outline the version changes, but I am doing that to reduce
> > friction and help committer to land my change. Thant's it. And
> > committers seem to have enough context from the provided version history
> > and memory of the previous iterations.
> >
> > Who this new ID benefits most is a system integrator that is tracking
> > all bits and pieces that are needed for their board to boot and work
> > properly. Hopefully the system integrator is a good community citizen
> > and not only wants to apply patches locally, but also make sure
> > stragglers end up in mainline after all. But they need additional
> > history to know whether the series was just forgotten, a new solution
> > was adopted instead, and so on.
> >
> > It also can help maintainers who need (maybe years later) to research
> > why particular change was made and whether there was additional
> > discussion around certain point of the change.
> >
> > The process you outlined above (collecting msg ids from previous
> > submissions, putting them into cover letter, etc) adds too much friction
> > at submission time so that submitters will not actually do any of that.
> > However having a git hook adding an ID to any new commit is much more
> > workable.
> 
> I don't think a git-hook will solve what Doug is asking. There is
> always some need for manual labor to add the metadata pointing to
> previous patch posting. How does anyone but the patch submitter know
> what the link/id/whatever of the previous patch posting or series is?
> Unless git has some telepathy abilities that I did not know about.

git does not know nor does it care. It simply records ID in the commit
message. That ID might be encoded as a link, or be just an ID to be
indexed later.

> 
> Since my day job involves gerrit usage, I have used gerrit and
> whenever I have a brand new patch for something; I have had to
> manually add the old Change-Id to the new change so that gerrit
> recognizes that it is linked to the old patch. That process is not
> done by a hook. Sure the initial generation is through a hook, but
> still.

Huh? In our set up the post-commit(?) hook checks the commit message and
adds Change-Id if it is not there yet. I have never needed to manually
add Change-Id...

Thanks.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 16:38                           ` Doug Anderson
@ 2019-08-23 16:50                             ` Andrew Lunn
  2019-08-23 17:50                               ` Doug Anderson
  0 siblings, 1 reply; 105+ messages in thread
From: Andrew Lunn @ 2019-08-23 16:50 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

> 1. Make it allowed or suggested to put a well-formed (machine
> parseable) Change-Id "after the cut" on mailing list posts, which
> would allow you to associate v1, v2, and v3.
> 
> 2. Add "Link://lkml.kernel.org/r/$MSGID_PER_PATCH" to landed patches,
> which would allow you to recover the Change-Id even after a patch
> lands.
> 
> ...then I will be happy (ish).  The biggest downside I see here is
> that it is much less likely that random committers out there will get
> this right.  The way committers naturally have the same Change-Id from
> v1 to v2 to v3 is because it's part of the commit message and when you
> amend to a previous change it stays there.  That means that these
> people will need to remember to move the Change-Id to "after the cut"
> unless we teach git-send-email to do this for you (though I guess
> maybe we could do that?).

To make this reliable, we really need git to be doing the work. We
should also think about the typical developer workflow.

To create a v1 of a patch, i do a git commit. To make a v2, i'm likely
to be using git rebase -i; git commit --am.

So why not have the initial git commit allocate the UUID. git commit
--am leaves the UUID alone. git-format-patch can then put the UUID
after the ---. Can git-send-email generate the MSGID from the UUID?

      Andrew

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 16:45                           ` Doug Anderson
@ 2019-08-23 16:54                             ` Joel Fernandes
  2019-08-23 18:00                               ` Doug Anderson
  0 siblings, 1 reply; 105+ messages in thread
From: Joel Fernandes @ 2019-08-23 16:54 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Fri, Aug 23, 2019 at 12:45 PM Doug Anderson <dianders@chromium.org> wrote:
[snip]
> Sure, if a given patch in the series is totally wrong and I re-write
> it (but still want the re-write to be considered a new version of the
> previous patch) then I have to manually copy the Change-Id for a
> gerrit upload.  ...but I'd also be OK if people just get a new
> Change-Id in this case.

Sometimes it is not "totally wrong" but just "done in a different
away" and is a new series. This happens a lot since upstream
development can be evolutionary. So your v1 may look nothing like v2
and is a whole new series. Yet the history linking the 2 series is
important. And no amount of automated commit ID generation can link
them. This is the scenario I was talking about. I know the git hook
works, but sometimes the Change-Id has to be manually copied. That's
not automatable. May be we are slightly on different tracks, but this
is the scenario that would be useful to trace IMO.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 16:50                             ` Andrew Lunn
@ 2019-08-23 17:50                               ` Doug Anderson
  0 siblings, 0 replies; 105+ messages in thread
From: Doug Anderson @ 2019-08-23 17:50 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi,

On Fri, Aug 23, 2019 at 9:50 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > 1. Make it allowed or suggested to put a well-formed (machine
> > parseable) Change-Id "after the cut" on mailing list posts, which
> > would allow you to associate v1, v2, and v3.
> >
> > 2. Add "Link://lkml.kernel.org/r/$MSGID_PER_PATCH" to landed patches,
> > which would allow you to recover the Change-Id even after a patch
> > lands.
> >
> > ...then I will be happy (ish).  The biggest downside I see here is
> > that it is much less likely that random committers out there will get
> > this right.  The way committers naturally have the same Change-Id from
> > v1 to v2 to v3 is because it's part of the commit message and when you
> > amend to a previous change it stays there.  That means that these
> > people will need to remember to move the Change-Id to "after the cut"
> > unless we teach git-send-email to do this for you (though I guess
> > maybe we could do that?).
>
> To make this reliable, we really need git to be doing the work. We
> should also think about the typical developer workflow.
>
> To create a v1 of a patch, i do a git commit. To make a v2, i'm likely
> to be using git rebase -i; git commit --am.
>
> So why not have the initial git commit allocate the UUID. git commit
> --am leaves the UUID alone. git-format-patch can then put the UUID
> after the ---. Can git-send-email generate the MSGID from the UUID?

Yes, if we can't agree to have Change-Id part of the commit that lands
as part of the kernel, then trying to get some smarts into
git-send-email and git-format-patch would definitely be the way to go.

-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 16:54                             ` Joel Fernandes
@ 2019-08-23 18:00                               ` Doug Anderson
  2019-08-23 19:08                                 ` Joel Fernandes
  0 siblings, 1 reply; 105+ messages in thread
From: Doug Anderson @ 2019-08-23 18:00 UTC (permalink / raw)
  To: Joel Fernandes
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

Hi,

On Fri, Aug 23, 2019 at 9:54 AM Joel Fernandes <joelaf@google.com> wrote:
>
> On Fri, Aug 23, 2019 at 12:45 PM Doug Anderson <dianders@chromium.org> wrote:
> [snip]
> > Sure, if a given patch in the series is totally wrong and I re-write
> > it (but still want the re-write to be considered a new version of the
> > previous patch) then I have to manually copy the Change-Id for a
> > gerrit upload.  ...but I'd also be OK if people just get a new
> > Change-Id in this case.
>
> Sometimes it is not "totally wrong" but just "done in a different
> away" and is a new series. This happens a lot since upstream
> development can be evolutionary. So your v1 may look nothing like v2
> and is a whole new series. Yet the history linking the 2 series is
> important. And no amount of automated commit ID generation can link
> them. This is the scenario I was talking about. I know the git hook
> works, but sometimes the Change-Id has to be manually copied. That's
> not automatable. May be we are slightly on different tracks, but this
> is the scenario that would be useful to trace IMO.

Agreed that it would be useful and (personally) I'd do it.  Maybe
others who are used to the gerrit workflow would also do it.  ...but
what I like is that the fallback for those that don't try to hard
isn't that terrible.  Yes they'd end up with a new Change-Id in some
cases, but presumably it still wouldn't be that hard for tools to help
you.  Namely, if you have a series:

Patch v1 1/3 - Add a frob - Change-Id A
Patch v1 2/3 - Add a larb - Change-Id B
Patch v1 3/3 - Use the frob to tweak the larb - Change-Id C

...and you decide that you should be tweaking a sneech instead of a
larb, you might end up with this if someone isn't careful to copy
Change-Ids and their workflow is to throw away the old patch #2 and #3
instead of amending.

Patch v2 1/3 - Add a frob - Change-Id A
Patch v2 2/3 - Add a sneech - Change-Id D
Patch v2 3/3 - Use the frob to tweak the sneech - Change-Id E

So you can't find v1 of patch #2 directly from v2 of patch #2.
...but, a good tool could still help you here.  It would see that at
least one patch in this series had the same Change-Id and it should
help you find the whole v1 series.

If all 3 patches were all totally new and lost Change IDs then I guess
you're SOL, but maybe in that case it really should be considered a
new series anyway?


-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  3:03             ` Linus Torvalds
  2019-08-23 13:15               ` Sean Paul
@ 2019-08-23 18:10               ` Konstantin Ryabitsev
  2019-08-26 22:19               ` Paul Mackerras
  2 siblings, 0 replies; 105+ messages in thread
From: Konstantin Ryabitsev @ 2019-08-23 18:10 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Thu, Aug 22, 2019 at 08:03:51PM -0700, Linus Torvalds wrote:
> Tangential note: since it looks like "Link:" lines are going to get
> more common in general, maybe somebody with the right tck/tk-fu can
> make a tool like 'gitk' be able to just do the hyperlinking thing (it
> already does it for commit hashes in the commit message, but wouldn't
> it be convenient to do that for web links too and open a browser
> tab?).
> 
> And maybe we can even make git.kernel.org do it too (I think that uses cgit?).

Yes, we should be able to do this with a simple hook -- both for Link:
and Message-ID bits. I'll put it on my list.

-K

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 18:00                               ` Doug Anderson
@ 2019-08-23 19:08                                 ` Joel Fernandes
  2019-08-23 19:15                                   ` Joel Fernandes
  2019-08-24 16:53                                   ` Doug Anderson
  0 siblings, 2 replies; 105+ messages in thread
From: Joel Fernandes @ 2019-08-23 19:08 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Fri, Aug 23, 2019 at 2:00 PM Doug Anderson <dianders@chromium.org> wrote:
[snip]
> > On Fri, Aug 23, 2019 at 12:45 PM Doug Anderson <dianders@chromium.org> wrote:
> > [snip]
> > > Sure, if a given patch in the series is totally wrong and I re-write
> > > it (but still want the re-write to be considered a new version of the
> > > previous patch) then I have to manually copy the Change-Id for a
> > > gerrit upload.  ...but I'd also be OK if people just get a new
> > > Change-Id in this case.
> >
> > Sometimes it is not "totally wrong" but just "done in a different
> > away" and is a new series. This happens a lot since upstream
> > development can be evolutionary. So your v1 may look nothing like v2
> > and is a whole new series. Yet the history linking the 2 series is
> > important. And no amount of automated commit ID generation can link
> > them. This is the scenario I was talking about. I know the git hook
> > works, but sometimes the Change-Id has to be manually copied. That's
> > not automatable. May be we are slightly on different tracks, but this
> > is the scenario that would be useful to trace IMO.
>
> Agreed that it would be useful and (personally) I'd do it.  Maybe
> others who are used to the gerrit workflow would also do it.  ...but
> what I like is that the fallback for those that don't try to hard
> isn't that terrible.  Yes they'd end up with a new Change-Id in some
> cases, but presumably it still wouldn't be that hard for tools to help
> you.  Namely, if you have a series:
>
> Patch v1 1/3 - Add a frob - Change-Id A
> Patch v1 2/3 - Add a larb - Change-Id B
> Patch v1 3/3 - Use the frob to tweak the larb - Change-Id C
>
> ...and you decide that you should be tweaking a sneech instead of a
> larb, you might end up with this if someone isn't careful to copy
> Change-Ids and their workflow is to throw away the old patch #2 and #3
> instead of amending.
>
> Patch v2 1/3 - Add a frob - Change-Id A
> Patch v2 2/3 - Add a sneech - Change-Id D
> Patch v2 3/3 - Use the frob to tweak the sneech - Change-Id E
>
> So you can't find v1 of patch #2 directly from v2 of patch #2.
> ...but, a good tool could still help you here.  It would see that at
> least one patch in this series had the same Change-Id and it should
> help you find the whole v1 series.
>
> If all 3 patches were all totally new and lost Change IDs then I guess
> you're SOL, but maybe in that case it really should be considered a
> new series anyway?

Maybe it should be. It is hard to generalize it to work all the time.
But I agree with you the above flow is better than nothing.

It does seem people need more convincing here though, that inserting a
unique ID into a commit message is acceptable.

Another thing that could be done is, have the git hook insert the
whatever-ID into the discardable part of the patch. The archive will
then have it even if the commit doesn't. Then something email2git or
patchwork can connect different patches in the archive with a
particular commit. I think Thomas Gleixner or someone else also
proposed something similar in this thread.  What's wrong with that
idea?

thanks,

 - Joel

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 19:08                                 ` Joel Fernandes
@ 2019-08-23 19:15                                   ` Joel Fernandes
  2019-08-23 19:23                                     ` Thomas Gleixner
  2019-08-24 16:53                                   ` Doug Anderson
  1 sibling, 1 reply; 105+ messages in thread
From: Joel Fernandes @ 2019-08-23 19:15 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Fri, Aug 23, 2019 at 3:08 PM Joel Fernandes <joelaf@google.com> wrote:
>
> On Fri, Aug 23, 2019 at 2:00 PM Doug Anderson <dianders@chromium.org> wrote:
> [snip]
> > > On Fri, Aug 23, 2019 at 12:45 PM Doug Anderson <dianders@chromium.org> wrote:
> > > [snip]
> > > > Sure, if a given patch in the series is totally wrong and I re-write
> > > > it (but still want the re-write to be considered a new version of the
> > > > previous patch) then I have to manually copy the Change-Id for a
> > > > gerrit upload.  ...but I'd also be OK if people just get a new
> > > > Change-Id in this case.
> > >
> > > Sometimes it is not "totally wrong" but just "done in a different
> > > away" and is a new series. This happens a lot since upstream
> > > development can be evolutionary. So your v1 may look nothing like v2
> > > and is a whole new series. Yet the history linking the 2 series is
> > > important. And no amount of automated commit ID generation can link
> > > them. This is the scenario I was talking about. I know the git hook
> > > works, but sometimes the Change-Id has to be manually copied. That's
> > > not automatable. May be we are slightly on different tracks, but this
> > > is the scenario that would be useful to trace IMO.
> >
> > Agreed that it would be useful and (personally) I'd do it.  Maybe
> > others who are used to the gerrit workflow would also do it.  ...but
> > what I like is that the fallback for those that don't try to hard
> > isn't that terrible.  Yes they'd end up with a new Change-Id in some
> > cases, but presumably it still wouldn't be that hard for tools to help
> > you.  Namely, if you have a series:
> >
> > Patch v1 1/3 - Add a frob - Change-Id A
> > Patch v1 2/3 - Add a larb - Change-Id B
> > Patch v1 3/3 - Use the frob to tweak the larb - Change-Id C
> >
> > ...and you decide that you should be tweaking a sneech instead of a
> > larb, you might end up with this if someone isn't careful to copy
> > Change-Ids and their workflow is to throw away the old patch #2 and #3
> > instead of amending.
> >
> > Patch v2 1/3 - Add a frob - Change-Id A
> > Patch v2 2/3 - Add a sneech - Change-Id D
> > Patch v2 3/3 - Use the frob to tweak the sneech - Change-Id E
> >
> > So you can't find v1 of patch #2 directly from v2 of patch #2.
> > ...but, a good tool could still help you here.  It would see that at
> > least one patch in this series had the same Change-Id and it should
> > help you find the whole v1 series.
> >
> > If all 3 patches were all totally new and lost Change IDs then I guess
> > you're SOL, but maybe in that case it really should be considered a
> > new series anyway?
>
> Maybe it should be. It is hard to generalize it to work all the time.
> But I agree with you the above flow is better than nothing.
>
> It does seem people need more convincing here though, that inserting a
> unique ID into a commit message is acceptable.

Just to clarify, here I meant "inserting of something other than a
message ID" into the commit message.

>
> Another thing that could be done is, have the git hook insert the

And, here I meant have git-send-email or the patch sending program
insert the unique ID into the discardable part.

In my flow, I have scripts that remove metadata from my commit message
and insert them into the discardable part of the patch already which I
use for "additional notes". I am not sure what it would take to have
people use such scripts...

> whatever-ID into the discardable part of the patch. The archive will
> then have it even if the commit doesn't. Then something email2git or
> patchwork can connect different patches in the archive with a
> particular commit. I think Thomas Gleixner or someone else also
> proposed something similar in this thread.  What's wrong with that
> idea?

 thanks,
- Joel

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 16:46                           ` Dmitry Torokhov
@ 2019-08-23 19:17                             ` Thomas Gleixner
  2019-08-23 19:38                               ` Laurent Pinchart
  2019-08-23 20:02                               ` Christian Brauner
  0 siblings, 2 replies; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-23 19:17 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Fri, 23 Aug 2019, Dmitry Torokhov wrote:
> On Fri, Aug 23, 2019 at 12:35:03PM -0400, Joel Fernandes wrote:
> > On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > > On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wrote:
> > > >
> > > > Yes, it's work for the submitter, but it's always work if the submitter
> > > > wants to have a proper trace.
> > >
> > > Here is where I disagree with you. As a patch submitter, I frankly could
> > > not care less about proper trace, history, etc. I might be putting cover
> > 
> > But that is exactly what the problem statement is. Doug does care
> > about tracing/history and wants that to be more robust etc.
> 
> Doug here is not a submitter ;)

Well, if he wants the changeids there then submitters need to insert them,
right? So it's work no matter what unless it can be automated with tooling.

Guess what, how I inject the Link to the coverletter of the previous
version of a patch series? Definitely not manualy. 

So yes, if you want proper traceability then all involved people have to do
something. If it can be done with tooling fully automated, fine. If not,
it's work whatever method you chose.

We cannot enforce the changeid thing in the community, but Google can
inforce it internally. So we give them a way to be traceable w/o plastering
the kernel logs with potentially useless information.

That said, I'm fine with a Link as well, as long as it is public
accessible. If not, then the coverletter/discard area is the place to use.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 19:15                                   ` Joel Fernandes
@ 2019-08-23 19:23                                     ` Thomas Gleixner
  2019-08-23 19:31                                       ` Joel Fernandes
  0 siblings, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-23 19:23 UTC (permalink / raw)
  To: Joel Fernandes
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Fri, 23 Aug 2019, Joel Fernandes via Ksummit-discuss wrote:
> On Fri, Aug 23, 2019 at 3:08 PM Joel Fernandes <joelaf@google.com> wrote:
> > Another thing that could be done is, have the git hook insert the
> 
> And, here I meant have git-send-email or the patch sending program
> insert the unique ID into the discardable part.
> 
> In my flow, I have scripts that remove metadata from my commit message
> and insert them into the discardable part of the patch already which I
> use for "additional notes". I am not sure what it would take to have
> people use such scripts...

Well, if some organization wants those IDs or whatever then they will come
up with proper tooling which enforces this. We won't ever be able to
enforce it on every submitter on the planet.

For maintainers we can make the Message-ID link mandatory if the community
agrees on it. git has some form of support for that already as I learned in
some other thread. And adding it to homebrewn tooling is not rocket science
either.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 19:23                                     ` Thomas Gleixner
@ 2019-08-23 19:31                                       ` Joel Fernandes
  0 siblings, 0 replies; 105+ messages in thread
From: Joel Fernandes @ 2019-08-23 19:31 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Fri, Aug 23, 2019 at 3:23 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Fri, 23 Aug 2019, Joel Fernandes via Ksummit-discuss wrote:
> > On Fri, Aug 23, 2019 at 3:08 PM Joel Fernandes <joelaf@google.com> wrote:
> > > Another thing that could be done is, have the git hook insert the
> >
> > And, here I meant have git-send-email or the patch sending program
> > insert the unique ID into the discardable part.
> >
> > In my flow, I have scripts that remove metadata from my commit message
> > and insert them into the discardable part of the patch already which I
> > use for "additional notes". I am not sure what it would take to have
> > people use such scripts...
>
> Well, if some organization wants those IDs or whatever then they will come
> up with proper tooling which enforces this. We won't ever be able to
> enforce it on every submitter on the planet.

Agreed.

> For maintainers we can make the Message-ID link mandatory if the community
> agrees on it. git has some form of support for that already as I learned in
> some other thread. And adding it to homebrewn tooling is not rocket science
> either.

Yep. I am curious now what support exists in git for this. I'll try to
look for that up, thanks!

- Joel

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 19:17                             ` Thomas Gleixner
@ 2019-08-23 19:38                               ` Laurent Pinchart
  2019-08-23 21:15                                 ` Thomas Gleixner
  2019-08-23 20:02                               ` Christian Brauner
  1 sibling, 1 reply; 105+ messages in thread
From: Laurent Pinchart @ 2019-08-23 19:38 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi Thomas,

On Fri, Aug 23, 2019 at 09:17:04PM +0200, Thomas Gleixner wrote:
> On Fri, 23 Aug 2019, Dmitry Torokhov wrote:
> > On Fri, Aug 23, 2019 at 12:35:03PM -0400, Joel Fernandes wrote:
> >> On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov wrote:
> >>> On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wrote:
> >>>>
> >>>> Yes, it's work for the submitter, but it's always work if the submitter
> >>>> wants to have a proper trace.
> >>>
> >>> Here is where I disagree with you. As a patch submitter, I frankly could
> >>> not care less about proper trace, history, etc. I might be putting cover
> >> 
> >> But that is exactly what the problem statement is. Doug does care
> >> about tracing/history and wants that to be more robust etc.
> > 
> > Doug here is not a submitter ;)
> 
> Well, if he wants the changeids there then submitters need to insert them,
> right? So it's work no matter what unless it can be automated with tooling.
> 
> Guess what, how I inject the Link to the coverletter of the previous
> version of a patch series? Definitely not manualy. 

Would you be able to share your method for automating this ? I'm sure
many kernel developers could benefit from such automation (both those
who insert links manually now, and those who don't insert links at all
because doing it manually is too tedious).

> So yes, if you want proper traceability then all involved people have to do
> something. If it can be done with tooling fully automated, fine. If not,
> it's work whatever method you chose.
> 
> We cannot enforce the changeid thing in the community, but Google can
> inforce it internally. So we give them a way to be traceable w/o plastering
> the kernel logs with potentially useless information.
> 
> That said, I'm fine with a Link as well, as long as it is public
> accessible. If not, then the coverletter/discard area is the place to use.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 19:17                             ` Thomas Gleixner
  2019-08-23 19:38                               ` Laurent Pinchart
@ 2019-08-23 20:02                               ` Christian Brauner
  2019-08-24 16:34                                 ` Doug Anderson
  1 sibling, 1 reply; 105+ messages in thread
From: Christian Brauner @ 2019-08-23 20:02 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

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

On Fri, Aug 23, 2019, 21:17 Thomas Gleixner <tglx@linutronix.de> wrote:

> On Fri, 23 Aug 2019, Dmitry Torokhov wrote:
> > On Fri, Aug 23, 2019 at 12:35:03PM -0400, Joel Fernandes wrote:
> > > On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov
> > > <dmitry.torokhov@gmail.com> wrote:
> > > > On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wrote:
> > > > >
> > > > > Yes, it's work for the submitter, but it's always work if the
> submitter
> > > > > wants to have a proper trace.
> > > >
> > > > Here is where I disagree with you. As a patch submitter, I frankly
> could
> > > > not care less about proper trace, history, etc. I might be putting
> cover
> > >
> > > But that is exactly what the problem statement is. Doug does care
> > > about tracing/history and wants that to be more robust etc.
> >
> > Doug here is not a submitter ;)
>
> Well, if he wants the changeids there then submitters need to insert them,
> right? So it's work no matter what unless it can be automated with tooling.
>
> Guess what, how I inject the Link to the coverletter of the previous
> version of a patch series? Definitely not manualy.
>
> So yes, if you want proper traceability then all involved people have to do
> something. If it can be done with tooling fully automated, fine. If not,
> it's work whatever method you chose.
>
> We cannot enforce the changeid thing in the community, but Google can
> inforce it internally. So we give them a way to be traceable w/o plastering
> the kernel logs with potentially useless information.
>
> That said, I'm fine with a Link as well, as long as it is public
>

A link is definitely more helpful then the change-id.
Quite a few maintainers are already making use of links to various sites
anyway so I don't see a good reason not allow Links to Gerrit or whatever.

accessible. If not, then the coverletter/discard area is the place to use.
>

Right, change-id should go after --- which is also what Dmitry Vyukov
suggested.

One thing I wonder though. What's the ultimate goal here?
Enabling people to review on Gerrit and lkml simultaneously?
I mean, apart from tracking versions of patch series/patches this can't be
all, right?
We can already do that right now and I'm already doing that when applying
stuff to my tree: inserting the link to the version of the patch set I
applied and linking to the previous version in each new version of the
patchset.
That could also be automated.
So is allowing reviews both on Gerrit or whatever the goal here and if so
how do we ensure that lkml sees all reviews?

Christian

[-- Attachment #2: Type: text/html, Size: 3651 bytes --]

<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 23, 2019, 21:17 Thomas Gleixner &lt;<a href="mailto:tglx@linutronix.de">tglx@linutronix.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 23 Aug 2019, Dmitry Torokhov wrote:<br>
&gt; On Fri, Aug 23, 2019 at 12:35:03PM -0400, Joel Fernandes wrote:<br>
&gt; &gt; On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov<br>
&gt; &gt; &lt;<a href="mailto:dmitry.torokhov@gmail.com" target="_blank" rel="noreferrer">dmitry.torokhov@gmail.com</a>&gt; wrote:<br>
&gt; &gt; &gt; On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wrote:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Yes, it&#39;s work for the submitter, but it&#39;s always work if the submitter<br>
&gt; &gt; &gt; &gt; wants to have a proper trace.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Here is where I disagree with you. As a patch submitter, I frankly could<br>
&gt; &gt; &gt; not care less about proper trace, history, etc. I might be putting cover<br>
&gt; &gt; <br>
&gt; &gt; But that is exactly what the problem statement is. Doug does care<br>
&gt; &gt; about tracing/history and wants that to be more robust etc.<br>
&gt; <br>
&gt; Doug here is not a submitter ;)<br>
<br>
Well, if he wants the changeids there then submitters need to insert them,<br>
right? So it&#39;s work no matter what unless it can be automated with tooling.<br>
<br>
Guess what, how I inject the Link to the coverletter of the previous<br>
version of a patch series? Definitely not manualy. <br>
<br>
So yes, if you want proper traceability then all involved people have to do<br>
something. If it can be done with tooling fully automated, fine. If not,<br>
it&#39;s work whatever method you chose.<br>
<br>
We cannot enforce the changeid thing in the community, but Google can<br>
inforce it internally. So we give them a way to be traceable w/o plastering<br>
the kernel logs with potentially useless information.<br>
<br>
That said, I&#39;m fine with a Link as well, as long as it is public<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">A link is definitely more helpful then the change-id.</div><div dir="auto">Quite a few maintainers are already making use of links to various sites anyway so I don&#39;t see a good reason not allow Links to Gerrit or whatever.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
accessible. If not, then the coverletter/discard area is the place to use.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Right, change-id should go after --- which is also what Dmitry Vyukov suggested.</div><div dir="auto"><br></div><div dir="auto">One thing I wonder though. What&#39;s the ultimate goal here?</div><div dir="auto">Enabling people to review on Gerrit and lkml simultaneously?</div><div dir="auto">I mean, apart from tracking versions of patch series/patches this can&#39;t be all, right?</div><div dir="auto">We can already do that right now and I&#39;m already doing that when applying stuff to my tree: inserting the link to the version of the patch set I applied and linking to the previous version in each new version of the patchset.</div><div dir="auto">That could also be automated.</div><div dir="auto">So is allowing reviews both on Gerrit or whatever the goal here and if so how do we ensure that lkml sees all reviews?</div><div dir="auto"><br></div><div dir="auto">Christian</div></div>

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 19:38                               ` Laurent Pinchart
@ 2019-08-23 21:15                                 ` Thomas Gleixner
  2019-08-23 21:25                                   ` Mark Brown
  2019-08-24 23:13                                   ` Theodore Y. Ts'o
  0 siblings, 2 replies; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-23 21:15 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Laurent,

On Fri, 23 Aug 2019, Laurent Pinchart wrote:
> On Fri, Aug 23, 2019 at 09:17:04PM +0200, Thomas Gleixner wrote:
> >
> > Guess what, how I inject the Link to the coverletter of the previous
> > version of a patch series? Definitely not manualy. 
> 
> Would you be able to share your method for automating this ? I'm sure
> many kernel developers could benefit from such automation (both those
> who insert links manually now, and those who don't insert links at all
> because doing it manually is too tedious).

You asked. Don't complain ...

I use quilt for all patch development work and also for my maintainer work,
IOW for everything. So I have tooling around that in and outside of emacs.

I store quilt queues (series file, patches, notes and some more) in git for
versioning. When I post a series I create a mbox with quilt and some custom
scripting around it.

Those scripts check whether there is already a mbox or several in the
patches directory and if not, then the resulting mbox name is mbox-0. If so
then the highest numbered mbox is looked up and the message id of the cover
letter extracted and injected into the template which is loaded into the
editor to write the cover letter. The resulting mbox name is
mbox-$HIGHEST+1. That mbox is then sent out and also archived in git.

For one off patches, I usally do not bother to save it. It's on the
mailing-list, right? So I utilize the method which I have for incoming
(maintainer work) stuff, which allows me to pick the patch from the list,
feed it through the usual machinery and then I have the msgid link as well,
which I then just move into the discard section when I send out V2. That's
also my workflow when I send out a quick fix for an issue in a reply
without changelog etc. If the reporter confirms, then I just pick it up,
add a changelog and commit it.

For incoming stuff, I just mark a full mailthread or several of them in the
mail client, store it as mbox and then I have a script which creates a
quilt series out of it. That script does a bunch of things:

    - Collect Reviewed-by, Acked-by, Tested-by tags either from individual
      replies or replies to the cover letter. The latter apply to the whole
      series.

    - Adds my Signed-off-by

    - Extract message-id for each patch and add the
      Link: https://lkml.kernel.org/r/$MSGID

    - A few magic things which I need for my emacs integration

I do that for review, applying patches and for development (addressing
feedback on a posted series).

Review usually only when it's complex stuff where I really need to see the
context. Emacs + quilt.el allows me to push/pop the patches, to see patch
and context, unapply/reapply hunks. I then can just create a reply from the
current patch (via Link...MSGID) by pulling out the original mail from the
mbox with more scripting magic and emacs shortcuts which are just burned
into my fingers, but I have to look them up in .emacs if someone asks what
I'm doing :)

When done, I just take the replies which I created on the way and send them
out. Either directly or I load them into the mail client when I want to
polish them some more.

For applying stuff, I also push/pop, review, do final tweaks if necessary,
polish the changelog etc. When I'm happy with the result then the series is
imported into git and pushed into a compile machine for basic checks and I
usually kick some smoke test as well. When thats all good I push it out
into my kernel.org tree and let 0-bot and Ingo's test machinery chew on it.

I also use that for development to address review feedback. So I can go
through the replies in the mbox, eventually write a reply, fixup the
corresponding patches, take notes which I can use for the next cover
letter, etc.

For backporting I have a git to quilt export, which I created for all that
speculation disaster work. That one inserts the 'commit xxxx upstream'
note. I use quilt for that because I'm so used to fix rejects in emacs or
to edit the patch (hunk) in the emacs window before applying it. Aside of
that my brain refuses to work with those git conflict markers and these
half consistent git states. That's like me and vi[m]. I just know how to
get out of the mess without creating further damage. :)

The scripts and tools are all highly undocumented and embarrassing hackery
glued together over two decades; IOW the kind of duct tape engineering
which I fundamentally dislike. :) At least most of my emacs quilt mess is
gone by now as someone with lisp brains did it proper.

That said, my git foo is limited and my oldschool habits have just grown
some warts to utilize the parts of git which I really need and like. Of
course all wrapped in scripts (bash, python, lisp) which hide the gory
details of command line arguments from my brain.

So I can't tell how that can be done in git, but I assume that it's
possible to tweak git-email (or what ever the command is) to emit that
message id and then stash it away in something like git notes for later
retrieval.

For the maintainer side there was something mentioned about some git-am
option which allows to insert the link somehow with some extra hook
magic. IIRC, it's in one of the ksummit threads, but I can't find it right
now.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 21:15                                 ` Thomas Gleixner
@ 2019-08-23 21:25                                   ` Mark Brown
  2019-08-24 23:13                                   ` Theodore Y. Ts'o
  1 sibling, 0 replies; 105+ messages in thread
From: Mark Brown @ 2019-08-23 21:25 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

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

On Fri, Aug 23, 2019 at 11:15:55PM +0200, Thomas Gleixner wrote:

> For the maintainer side there was something mentioned about some git-am
> option which allows to insert the link somehow with some extra hook
> magic. IIRC, it's in one of the ksummit threads, but I can't find it right
> now.

It was to have this:

. git-sh-setup
perl -pi -e 's|^Message-Id:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1"

in your .git/hooks/applypatch-msg.

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 20:02                               ` Christian Brauner
@ 2019-08-24 16:34                                 ` Doug Anderson
  2019-08-24 18:11                                   ` Linus Torvalds
  0 siblings, 1 reply; 105+ messages in thread
From: Doug Anderson @ 2019-08-24 16:34 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi,

On Fri, Aug 23, 2019 at 1:02 PM Christian Brauner <christian@brauner.io> wrote:
>
>
>
> On Fri, Aug 23, 2019, 21:17 Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> On Fri, 23 Aug 2019, Dmitry Torokhov wrote:
>> > On Fri, Aug 23, 2019 at 12:35:03PM -0400, Joel Fernandes wrote:
>> > > On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov
>> > > <dmitry.torokhov@gmail.com> wrote:
>> > > > On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wrote:
>> > > > >
>> > > > > Yes, it's work for the submitter, but it's always work if the submitter
>> > > > > wants to have a proper trace.
>> > > >
>> > > > Here is where I disagree with you. As a patch submitter, I frankly could
>> > > > not care less about proper trace, history, etc. I might be putting cover
>> > >
>> > > But that is exactly what the problem statement is. Doug does care
>> > > about tracing/history and wants that to be more robust etc.
>> >
>> > Doug here is not a submitter ;)
>>
>> Well, if he wants the changeids there then submitters need to insert them,
>> right? So it's work no matter what unless it can be automated with tooling.
>>
>> Guess what, how I inject the Link to the coverletter of the previous
>> version of a patch series? Definitely not manualy.
>>
>> So yes, if you want proper traceability then all involved people have to do
>> something. If it can be done with tooling fully automated, fine. If not,
>> it's work whatever method you chose.
>>
>> We cannot enforce the changeid thing in the community, but Google can
>> inforce it internally. So we give them a way to be traceable w/o plastering
>> the kernel logs with potentially useless information.
>>
>> That said, I'm fine with a Link as well, as long as it is public
>
>
> A link is definitely more helpful then the change-id.
> Quite a few maintainers are already making use of links to various sites anyway so I don't see a good reason not allow Links to Gerrit or whatever.

Just wanted to mention again that for the use case I'm trying to
solve: there is no link.

Here is the relevant part of the email chain explaining:

I have no gerrit server involved when I submit patches to the list.  I do:

1. Write patch on my local machine.
2. Post v1 to mailing list.
3. Make changes.
4. Post v2 to mailing list.
5. Make changes.
5. Post v3 to mailing list.

I have never uploaded to a gerrit in this process.  THERE IS NO GERRIT LINK!

>> accessible. If not, then the coverletter/discard area is the place to use.
>
>
> Right, change-id should go after --- which is also what Dmitry Vyukov suggested.

It is not my favorite because it will have less adoption (people will
need to manually move the Change-Id or adopt new tools that do this
for them).  The advantage of keeping Change-Id above the cut is that
those who have adopted the git hooks that gerrit requires (and there
appears to be a lot of people who use gerrit) will magically start
doing the right thing instead of getting yelled at.  Overall the
success of this depends on submitters adopting it and submitters are
much harder to influence than maintainers (and that's saying a lot).

That all being said: I guess I will settle for not getting yelled at
for Change-Id existing after-the-cut.  Is anyone on this thread upset
if people put Change-Id after-the-cut?


> One thing I wonder though. What's the ultimate goal here?
> Enabling people to review on Gerrit and lkml simultaneously?
> I mean, apart from tracking versions of patch series/patches this can't be all, right?

Ultimate goal: to allow tools (maybe gerrit, maybe patchwork, maybe
something entirely new) to identify when a patch is a newer version of
an old one.  Yes, that might someday allow a nice integration of
gerrit with kernel mailing lists.

Short term goal: allow people to manually find patch v1 from patch v2
using text search.  ...or to find all mailing list discussion from a
landed patch.  Example of how short term goal works (from earlier in
the thread):

https://lore.kernel.org/lkml/?q=Change-Id%3A+I23e218cd964f16c0b2b26127d4a5ca6529867673


> We can already do that right now and I'm already doing that when applying stuff to my tree: inserting the link to the version of the patch set I applied and linking to the previous version in each new version of the patchset.
> That could also be automated.
> So is allowing reviews both on Gerrit or whatever the goal here and if so how do we ensure that lkml sees all reviews?

The flow I'm talking about doesn't depend on ANY gerrit.  There is no
server and there are no private reviews.  There is only a Change-Id
linking versions of patches.

IF (and only if) someone wanted to make a gerrit (or several gerrits)
that scraped LKML and created a gerrit change for each new patch, this
Change Id could be useful to them.  Presumably nobody would care if
someone made a private comment on one of those gerrits.  ...but if
gerrit every fully integrated email lists then (you could imagine)
that publishing your review on gerrit would send it out to the lists.
Any other gerrits that also happened to be scraping LKML would notice
this review and (presumably) mirror the comments on their own gerrit.

So in my mind allowing Change-Id preserves the distributed mailing
list centric workflow of the kernel but would help people implement a
GUI.

-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 19:08                                 ` Joel Fernandes
  2019-08-23 19:15                                   ` Joel Fernandes
@ 2019-08-24 16:53                                   ` Doug Anderson
  1 sibling, 0 replies; 105+ messages in thread
From: Doug Anderson @ 2019-08-24 16:53 UTC (permalink / raw)
  To: Joel Fernandes
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

Hi,

On Fri, Aug 23, 2019 at 12:08 PM Joel Fernandes <joelaf@google.com> wrote:
>
> On Fri, Aug 23, 2019 at 2:00 PM Doug Anderson <dianders@chromium.org> wrote:
> [snip]
> > > On Fri, Aug 23, 2019 at 12:45 PM Doug Anderson <dianders@chromium.org> wrote:
> > > [snip]
> > > > Sure, if a given patch in the series is totally wrong and I re-write
> > > > it (but still want the re-write to be considered a new version of the
> > > > previous patch) then I have to manually copy the Change-Id for a
> > > > gerrit upload.  ...but I'd also be OK if people just get a new
> > > > Change-Id in this case.
> > >
> > > Sometimes it is not "totally wrong" but just "done in a different
> > > away" and is a new series. This happens a lot since upstream
> > > development can be evolutionary. So your v1 may look nothing like v2
> > > and is a whole new series. Yet the history linking the 2 series is
> > > important. And no amount of automated commit ID generation can link
> > > them. This is the scenario I was talking about. I know the git hook
> > > works, but sometimes the Change-Id has to be manually copied. That's
> > > not automatable. May be we are slightly on different tracks, but this
> > > is the scenario that would be useful to trace IMO.
> >
> > Agreed that it would be useful and (personally) I'd do it.  Maybe
> > others who are used to the gerrit workflow would also do it.  ...but
> > what I like is that the fallback for those that don't try to hard
> > isn't that terrible.  Yes they'd end up with a new Change-Id in some
> > cases, but presumably it still wouldn't be that hard for tools to help
> > you.  Namely, if you have a series:
> >
> > Patch v1 1/3 - Add a frob - Change-Id A
> > Patch v1 2/3 - Add a larb - Change-Id B
> > Patch v1 3/3 - Use the frob to tweak the larb - Change-Id C
> >
> > ...and you decide that you should be tweaking a sneech instead of a
> > larb, you might end up with this if someone isn't careful to copy
> > Change-Ids and their workflow is to throw away the old patch #2 and #3
> > instead of amending.
> >
> > Patch v2 1/3 - Add a frob - Change-Id A
> > Patch v2 2/3 - Add a sneech - Change-Id D
> > Patch v2 3/3 - Use the frob to tweak the sneech - Change-Id E
> >
> > So you can't find v1 of patch #2 directly from v2 of patch #2.
> > ...but, a good tool could still help you here.  It would see that at
> > least one patch in this series had the same Change-Id and it should
> > help you find the whole v1 series.
> >
> > If all 3 patches were all totally new and lost Change IDs then I guess
> > you're SOL, but maybe in that case it really should be considered a
> > new series anyway?
>
> Maybe it should be. It is hard to generalize it to work all the time.
> But I agree with you the above flow is better than nothing.
>
> It does seem people need more convincing here though, that inserting a
> unique ID into a commit message is acceptable.
>
> Another thing that could be done is, have the git hook insert the
> whatever-ID into the discardable part of the patch. The archive will
> then have it even if the commit doesn't. Then something email2git or
> patchwork can connect different patches in the archive with a
> particular commit. I think Thomas Gleixner or someone else also
> proposed something similar in this thread.  What's wrong with that
> idea?

Right.  The thread is hard to follow, but earlier in the thread I said
I would be happy (ish) with this.  If there is no resolution to this
topic then I will likely start doing this myself and point to this
thread when I get yelled at for it.  ;-)  Unless someone tells me that
this would absolutely not be OK.

The reason that Change-Id after-the-cut is slightly less optimal is
that this whole thing only becomes useful if patch submitters actually
do it.  ...and patch submitters are VERY hard to train.  Patch
submitters are already (accidentally) leaving the Change-Id before the
cut because they already have a commit hook that puts it there for
them.  Thus we have a built-in set of people for whom no training is
needed and no new tools are needed.  That is a huge benefit.  There
are others that already have the Change-Id and (today) have to
manually remove it.  Presumably those people wouldn't need much
training or convincing.

...so I guess I'll still leave a little hope that people will accept
Change-Id as part of the commit message now that I've responded to the
outstanding feedback and showed the benefits...

Please know that I'm not trying to advance a hidden agenda to take
over the world or make gerrit the one true tool or get rid of existing
email workflows.  I'm just trying to get a tag to be allowed that
seems to be genuinely useful.

-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-24 16:34                                 ` Doug Anderson
@ 2019-08-24 18:11                                   ` Linus Torvalds
  2019-08-24 23:04                                     ` Theodore Y. Ts'o
  2019-08-26 17:13                                     ` Doug Anderson
  0 siblings, 2 replies; 105+ messages in thread
From: Linus Torvalds @ 2019-08-24 18:11 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	Dmitry Vyukov, David Rientjes, Dmitry Torokhov

On Sat, Aug 24, 2019 at 9:35 AM Doug Anderson <dianders@chromium.org> wrote:
>
> I have no gerrit server involved when I submit patches to the list.  I do:
>
> 1. Write patch on my local machine.
> 2. Post v1 to mailing list.
> 3. Make changes.
> 4. Post v2 to mailing list.
> 5. Make changes.
> 5. Post v3 to mailing list.
>
> I have never uploaded to a gerrit in this process.  THERE IS NO GERRIT LINK!

First off, there *is* a link - just use the mailing list email link
(preferably for the cover letter - so that a whole series has _one_
ID, not separate ID's for every patch) just like everybody else does,
which also means that you get the history of actual other developers
replying to it (including after it has been committed).

The first time it gets magically and reliably created for you without
you having to do a single thing. The second time, you just look it up.

Ta-daa - you have a "uuid" that is useful to others, and that
describes the whole series unambiguously.

So the mailing list archive link is objectively better. You don't have
to make up some new way to generate a unique ID - one already exists.

Any other UUID would be completely pointless. And don't try to argue
that it is anything _but_ pointless. As far as everybody else in the
whole wide world is concerned, it would be better if you just pointed
to the original submission, not to some
made-up-makes-sense-only-to-you UUID that others would have to google
and hope for the best.

End result: if you actually want to be useful to *other* people, then
when you do your "v2" posting of the patch series, instead of that
completely useless UUID, just link to the previous posted version in
the new cover letter.

Now that link exists and is useful for others too, both from a git
history standpoint, but also from a "look, this is the last time I
posted this, just to remind you, or you can go look at the comments
then and verify that they got fixed up".

In other words, stop arguing for an objectively much worse UUID.

You can have it locally if you want to, but realize that NOBODY ELSE
finds it the least useful at all. It's just random noise you yourself
generated for your own use, and isn't interesting or relevant to
anybody else.

In contrast, if you actually put a link to a previous conversation,
that link will be valid and useful even if

 (a) it wasn't even a previous conversion on that mailing list at all,
but a link to something like a bugzilla entry, or a CPU vendor errata
sheet or whatever

 (b) even if it was a previous conversation on the mailing list, maybe
it wasn't one that you started, but you're instead basing your series
(partially or wholly) on somebody elses earlier work.

Notice how a UUID fundamentally could not handle either of the above
obvious cases. Nobody else generates a uuid for you (except for that
message-id-uuid that already exists).

So stop arguing for UUID's. They are fundamentally a bad idea.

The *only* actual valid reason I have ever seen for UUID's (and yes,
this is not the first time they've been brought up, which is why I
hate them with a passion) is to use it as a magic link inside some
vendors private database when that vendor doesn't want to expose any
actual real information.

In other words: UUID's are bad and pointless. Their only "valid" use
is explicitly against the whole point of open development.

Use an actual open standard instead: a web link. It can be anything.
It can be a link to a previous version, it can be a link to further
documentation, it can be a link to _anything_ on the internet for
later reference.

And if it isn't on the internet visible to everybody else, then it
should be described outright in the commit message itself. Or it
shouldn't be there at all.

Are there other possibly valid things? Yes. But they do not include UUID's.

For example, if you want to refer to something in the physical world,
and you can't find a link to it online, by all means use other
standard and public ways to do that. Use the ISBN for a book or an
ISSN for a magazine. Or use the address for a physical location,
whatever. That's not a random and meaningless number, it's something
useful that can be looked up later and thus quite possibly worth
saving in a commit message.

There are probably hundreds of those "useful to be looked up later"
things. But a UUID is not one of them.

              Linus

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-24 18:11                                   ` Linus Torvalds
@ 2019-08-24 23:04                                     ` Theodore Y. Ts'o
  2019-08-25  3:11                                       ` Greg Kroah-Hartman
  2019-08-26 17:13                                     ` Doug Anderson
  1 sibling, 1 reply; 105+ messages in thread
From: Theodore Y. Ts'o @ 2019-08-24 23:04 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Sat, Aug 24, 2019 at 11:11:32AM -0700, Linus Torvalds wrote:
> The first time it gets magically and reliably created for you without
> you having to do a single thing. The second time, you just look it up.

Also, if you don't want to look it up, and want to have it generated
"locally", the Message-Id is generated locally by git send-email.
(That's right, Message-Id's are just as easy to generate locally as
UUID's.)  It will look like this:

     Message-Id: <20190824223355.12947-1-tytso@mit.edu>

So if someone wants to make life easier for people who want to send
out the V2 version of the patch, it would be possible for someone to
write some tooling which saves the generated Message-Id by git
send-email (and if you generate the message id and drop it into the
files generated by git format-patch, git send-email will use the
generated message id), so that can get used for the git commit
description for the next version of the commit, this can be done in a
completely automated way, without having to do any kind of lookups.

As far as I'm concerned, Message-Id's or Link's are both strictly
superior than a random 16-byte Change-Id UUID.

						- Ted

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23 21:15                                 ` Thomas Gleixner
  2019-08-23 21:25                                   ` Mark Brown
@ 2019-08-24 23:13                                   ` Theodore Y. Ts'o
  2019-08-25  7:09                                     ` Thomas Gleixner
  1 sibling, 1 reply; 105+ messages in thread
From: Theodore Y. Ts'o @ 2019-08-24 23:13 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Fri, Aug 23, 2019 at 11:15:55PM +0200, Thomas Gleixner wrote:
> For incoming stuff, I just mark a full mailthread or several of them in the
> mail client, store it as mbox and then I have a script which creates a
> quilt series out of it. That script does a bunch of things:
> 
>     - Collect Reviewed-by, Acked-by, Tested-by tags either from individual
>       replies or replies to the cover letter. The latter apply to the whole
>       series.
> 
>     - Adds my Signed-off-by
> 
>     - Extract message-id for each patch and add the
>       Link: https://lkml.kernel.org/r/$MSGID
> 
>     - A few magic things which I need for my emacs integration

I use quilt for processing incoming changes for ext4 as well; would
you mind sharing your script?  This sounds like it would be really
useful for me.

Thanks!!

						- Ted

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-24 23:04                                     ` Theodore Y. Ts'o
@ 2019-08-25  3:11                                       ` Greg Kroah-Hartman
  2019-08-27 10:51                                         ` Mark Brown
  0 siblings, 1 reply; 105+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-25  3:11 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Dmitry Torokhov,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Vyukov

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

On Sat, Aug 24, 2019 at 07:04:47PM -0400, Theodore Y. Ts'o wrote:
> On Sat, Aug 24, 2019 at 11:11:32AM -0700, Linus Torvalds wrote:
> > The first time it gets magically and reliably created for you without
> > you having to do a single thing. The second time, you just look it up.
> 
> Also, if you don't want to look it up, and want to have it generated
> "locally", the Message-Id is generated locally by git send-email.
> (That's right, Message-Id's are just as easy to generate locally as
> UUID's.)  It will look like this:
> 
>      Message-Id: <20190824223355.12947-1-tytso@mit.edu>

I know we are getting "off-topic" here, but as people are sharing
scripts, it turns out that I have been generating my own "message-ids"
for the emails my scripts send out for accepted patches for years with
the attached simple script.

Odds are it was based on a bash script from akpm, but maybe it came from
somewhere else, I've had it around for so long the history of it is
long-lost.

> So if someone wants to make life easier for people who want to send
> out the V2 version of the patch, it would be possible for someone to
> write some tooling which saves the generated Message-Id by git
> send-email (and if you generate the message id and drop it into the
> files generated by git format-patch, git send-email will use the
> generated message id), so that can get used for the git commit
> description for the next version of the commit, this can be done in a
> completely automated way, without having to do any kind of lookups.

When accepting patches from people, my old scripts used to do this
properly and reply to the sent message-id.  Now that I use git, that's
lost, except that I now am generating Link: tags in the commit message
itself, like:
	Link: https://lore.kernel.org/r/20190822213659.5501-1-hsiangkao@aol.com

Hm, I guess I do now keep that info, and I can fix my scripts to
properly thread things, let me go work on that later today...

> As far as I'm concerned, Message-Id's or Link's are both strictly
> superior than a random 16-byte Change-Id UUID.

I totally agree, there's more data in a message-id than a change-id by
far.

Sorry Doug, but this thread turned out kind of like I expected it to,
hopefully you have been convinced better than I did when we spoke in
person :)

thanks,

greg k-h

[-- Attachment #2: make_message_id --]
[-- Type: text/plain, Size: 659 bytes --]

#!/usr/bin/perl

# we make a "fake" message id by taking the current number of seconds
# since the beginning of Unix time and tacking on two random numbers to
# the end, in case we are called quicker than 1 second since the last
# time we were called.

use strict;

my $date = `date "+\%s"`;
my $hostname = `hostname -d`;
chomp($date);
chomp($hostname);

my $pseudo_rand;

open FILE, "<:raw", "/dev/urandom" or die "Couldn't open /dev/urandom !";

sysread(FILE, $pseudo_rand, 1);
my $rand1 = ord($pseudo_rand);

sysread(FILE, $pseudo_rand, 1);
my $rand2 = ord($pseudo_rand);

my $message_id = "$date$rand1$rand2\@$hostname";
print "$message_id";

close FILE;

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-24 23:13                                   ` Theodore Y. Ts'o
@ 2019-08-25  7:09                                     ` Thomas Gleixner
  2019-08-26 22:05                                       ` Thomas Gleixner
  0 siblings, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-25  7:09 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Sat, 24 Aug 2019, Theodore Y. Ts'o wrote:
> On Fri, Aug 23, 2019 at 11:15:55PM +0200, Thomas Gleixner wrote:
> > For incoming stuff, I just mark a full mailthread or several of them in the
> > mail client, store it as mbox and then I have a script which creates a
> > quilt series out of it. That script does a bunch of things:
> > 
> >     - Collect Reviewed-by, Acked-by, Tested-by tags either from individual
> >       replies or replies to the cover letter. The latter apply to the whole
> >       series.
> > 
> >     - Adds my Signed-off-by
> > 
> >     - Extract message-id for each patch and add the
> >       Link: https://lkml.kernel.org/r/$MSGID
> > 
> >     - A few magic things which I need for my emacs integration
> 
> I use quilt for processing incoming changes for ext4 as well; would
> you mind sharing your script?  This sounds like it would be really
> useful for me.

Sure. Give me a day or two to make it less embarrassing by removing the
duct tape it grew over time. :)

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-24 18:11                                   ` Linus Torvalds
  2019-08-24 23:04                                     ` Theodore Y. Ts'o
@ 2019-08-26 17:13                                     ` Doug Anderson
  2019-08-26 17:30                                       ` Joel Fernandes
  1 sibling, 1 reply; 105+ messages in thread
From: Doug Anderson @ 2019-08-26 17:13 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	Dmitry Vyukov, David Rientjes, Dmitry Torokhov

Hi,

On Sat, Aug 24, 2019 at 11:11 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sat, Aug 24, 2019 at 9:35 AM Doug Anderson <dianders@chromium.org> wrote:
> >
> > I have no gerrit server involved when I submit patches to the list.  I do:
> >
> > 1. Write patch on my local machine.
> > 2. Post v1 to mailing list.
> > 3. Make changes.
> > 4. Post v2 to mailing list.
> > 5. Make changes.
> > 5. Post v3 to mailing list.
> >
> > I have never uploaded to a gerrit in this process.  THERE IS NO GERRIT LINK!
>
> First off, there *is* a link - just use the mailing list email link
> (preferably for the cover letter - so that a whole series has _one_
> ID, not separate ID's for every patch) just like everybody else does,
> which also means that you get the history of actual other developers
> replying to it (including after it has been committed).
>
> The first time it gets magically and reliably created for you without
> you having to do a single thing. The second time, you just look it up.

The key problem here is that it requires the committer to look
something up and perform a manual step.  IMO this means that the
adoption rate will be near to zero.  The reason that Change-Id
_doesn't_ require a manual step is that it's in your local commit
message and thus automatically stays there.  Thus inaction (leaving
the Change-Id alone as you spin the patch) produces the ideal
behavior.


> Ta-daa - you have a "uuid" that is useful to others, and that
> describes the whole series unambiguously.
>
> So the mailing list archive link is objectively better. You don't have
> to make up some new way to generate a unique ID - one already exists.
>
> Any other UUID would be completely pointless. And don't try to argue
> that it is anything _but_ pointless. As far as everybody else in the
> whole wide world is concerned, it would be better if you just pointed
> to the original submission, not to some
> made-up-makes-sense-only-to-you UUID that others would have to google
> and hope for the best.
>
> End result: if you actually want to be useful to *other* people, then
> when you do your "v2" posting of the patch series, instead of that
> completely useless UUID, just link to the previous posted version in
> the new cover letter.
>
> Now that link exists and is useful for others too, both from a git
> history standpoint, but also from a "look, this is the last time I
> posted this, just to remind you, or you can go look at the comments
> then and verify that they got fixed up".
>
> In other words, stop arguing for an objectively much worse UUID.
>
> You can have it locally if you want to, but realize that NOBODY ELSE
> finds it the least useful at all. It's just random noise you yourself
> generated for your own use, and isn't interesting or relevant to
> anybody else.
>
> In contrast, if you actually put a link to a previous conversation,
> that link will be valid and useful even if
>
>  (a) it wasn't even a previous conversion on that mailing list at all,
> but a link to something like a bugzilla entry, or a CPU vendor errata
> sheet or whatever
>
>  (b) even if it was a previous conversation on the mailing list, maybe
> it wasn't one that you started, but you're instead basing your series
> (partially or wholly) on somebody elses earlier work.
>
> Notice how a UUID fundamentally could not handle either of the above
> obvious cases. Nobody else generates a uuid for you (except for that
> message-id-uuid that already exists).
>
> So stop arguing for UUID's. They are fundamentally a bad idea.
>
> The *only* actual valid reason I have ever seen for UUID's (and yes,
> this is not the first time they've been brought up, which is why I
> hate them with a passion) is to use it as a magic link inside some
> vendors private database when that vendor doesn't want to expose any
> actual real information.

What I see here is:

1. A valid reason to have a UUID is to help a machine that's
processing data.  Specifically UUIDs are well-formed and easy for a
machine to understand (unlike a link which could point to anything).

2. In the past you don't like UUIDs because the machines making sense
of them are private.

In this thread I am trying to argue that if we allow UUIDs in the
public email lists that anyone will be able to create a useful and
public database linking patch versions together.


> In other words: UUID's are bad and pointless. Their only "valid" use
> is explicitly against the whole point of open development.
>
> Use an actual open standard instead: a web link. It can be anything.

The "It can be anything" is the problem with links.  Computers trying
to parse things like to have well-formed and well defined information.
Presumably if we had any chance of having computers parse these links
we need to have a _very_ will defined format for how a new version of
the patch points to the previous versions.  Everyone has to agree to
use the exact same well defined format.

--

NOTE: from reading all of this, one thing that I should probably be
able to do myself is:

1. Keep having Change-Id in my patches on my local computer.

2. Have the scripts I use to post upstream (which strips Change-Id out
before posting) encode the Change-Id into the Message-Id in a way that
it could be recovered, like:

Message-Id: Ic3e54798e4aeaa862b2e8eebcbbcef4e51ccae19-2018-1231-235959-1

...presumably that would have zero objections from anyone, but would
also be nearly useless since only my own patches would honor this
convention and the whole point is to later enable a machine to parse
them.


-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 17:13                                     ` Doug Anderson
@ 2019-08-26 17:30                                       ` Joel Fernandes
  2019-08-26 21:35                                         ` Doug Anderson
  0 siblings, 1 reply; 105+ messages in thread
From: Joel Fernandes @ 2019-08-26 17:30 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Barret Rhoden, Dmitry Torokhov, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	Dmitry Vyukov, David Rientjes

On Mon, Aug 26, 2019 at 1:13 PM Doug Anderson <dianders@chromium.org> wrote:
> On Sat, Aug 24, 2019 at 11:11 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Sat, Aug 24, 2019 at 9:35 AM Doug Anderson <dianders@chromium.org> wrote:
> > >
> > > I have no gerrit server involved when I submit patches to the list.  I do:
> > >
> > > 1. Write patch on my local machine.
> > > 2. Post v1 to mailing list.
> > > 3. Make changes.
> > > 4. Post v2 to mailing list.
> > > 5. Make changes.
> > > 5. Post v3 to mailing list.
> > >
> > > I have never uploaded to a gerrit in this process.  THERE IS NO GERRIT LINK!
> >
> > First off, there *is* a link - just use the mailing list email link
> > (preferably for the cover letter - so that a whole series has _one_
> > ID, not separate ID's for every patch) just like everybody else does,
> > which also means that you get the history of actual other developers
> > replying to it (including after it has been committed).
> >
> > The first time it gets magically and reliably created for you without
> > you having to do a single thing. The second time, you just look it up.
>
> The key problem here is that it requires the committer to look
> something up and perform a manual step.  IMO this means that the
> adoption rate will be near to zero.  The reason that Change-Id
> _doesn't_ require a manual step is that it's in your local commit
> message and thus automatically stays there.  Thus inaction (leaving
> the Change-Id alone as you spin the patch) produces the ideal
> behavior.

Sure, but..

> >
> > So stop arguing for UUID's. They are fundamentally a bad idea.
> >
> > The *only* actual valid reason I have ever seen for UUID's (and yes,
> > this is not the first time they've been brought up, which is why I
> > hate them with a passion) is to use it as a magic link inside some
> > vendors private database when that vendor doesn't want to expose any
> > actual real information.
>
> What I see here is:
>
> 1. A valid reason to have a UUID is to help a machine that's
> processing data.  Specifically UUIDs are well-formed and easy for a
> machine to understand (unlike a link which could point to anything).

I don't think a "link could point to anything" is a good argument
against links. A link to lore.kernel.org/r/<message-id> should point
to only one thing.

> 2. In the past you don't like UUIDs because the machines making sense
> of them are private.
>
> In this thread I am trying to argue that if we allow UUIDs in the
> public email lists that anyone will be able to create a useful and
> public database linking patch versions together.

Did you read all the emails that said these can be inserted into the
discardable part of a patch? Enforcing it on everyone in the community
is impossible.

> > In other words: UUID's are bad and pointless. Their only "valid" use
> > is explicitly against the whole point of open development.
> >
> > Use an actual open standard instead: a web link. It can be anything.
>
> The "It can be anything" is the problem with links.  Computers trying

I think he meant it can be any link. But what a link points to
(lore.kernel.org/r/<message-id>) largely should not change.

> NOTE: from reading all of this, one thing that I should probably be
> able to do myself is:
>
> 1. Keep having Change-Id in my patches on my local computer.
>
> 2. Have the scripts I use to post upstream (which strips Change-Id out
> before posting) encode the Change-Id into the Message-Id in a way that
> it could be recovered, like:
>
> Message-Id: Ic3e54798e4aeaa862b2e8eebcbbcef4e51ccae19-2018-1231-235959-1

Why not just put whatever-ID in the discardable part of your patch as
others have also pointed, and move on?

thanks,

 - Joel

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 17:30                                       ` Joel Fernandes
@ 2019-08-26 21:35                                         ` Doug Anderson
  2019-08-26 21:51                                           ` Thomas Gleixner
  2019-08-26 23:02                                           ` Theodore Y. Ts'o
  0 siblings, 2 replies; 105+ messages in thread
From: Doug Anderson @ 2019-08-26 21:35 UTC (permalink / raw)
  To: Joel Fernandes
  Cc: Barret Rhoden, Dmitry Torokhov, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	Dmitry Vyukov, David Rientjes

Hi,

On Mon, Aug 26, 2019 at 10:31 AM Joel Fernandes <joelaf@google.com> wrote:
>
> On Mon, Aug 26, 2019 at 1:13 PM Doug Anderson <dianders@chromium.org> wrote:
> > On Sat, Aug 24, 2019 at 11:11 AM Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > > On Sat, Aug 24, 2019 at 9:35 AM Doug Anderson <dianders@chromium.org> wrote:
> > > >
> > > > I have no gerrit server involved when I submit patches to the list.  I do:
> > > >
> > > > 1. Write patch on my local machine.
> > > > 2. Post v1 to mailing list.
> > > > 3. Make changes.
> > > > 4. Post v2 to mailing list.
> > > > 5. Make changes.
> > > > 5. Post v3 to mailing list.
> > > >
> > > > I have never uploaded to a gerrit in this process.  THERE IS NO GERRIT LINK!
> > >
> > > First off, there *is* a link - just use the mailing list email link
> > > (preferably for the cover letter - so that a whole series has _one_
> > > ID, not separate ID's for every patch) just like everybody else does,
> > > which also means that you get the history of actual other developers
> > > replying to it (including after it has been committed).
> > >
> > > The first time it gets magically and reliably created for you without
> > > you having to do a single thing. The second time, you just look it up.
> >
> > The key problem here is that it requires the committer to look
> > something up and perform a manual step.  IMO this means that the
> > adoption rate will be near to zero.  The reason that Change-Id
> > _doesn't_ require a manual step is that it's in your local commit
> > message and thus automatically stays there.  Thus inaction (leaving
> > the Change-Id alone as you spin the patch) produces the ideal
> > behavior.
>
> Sure, but..
>
> > >
> > > So stop arguing for UUID's. They are fundamentally a bad idea.
> > >
> > > The *only* actual valid reason I have ever seen for UUID's (and yes,
> > > this is not the first time they've been brought up, which is why I
> > > hate them with a passion) is to use it as a magic link inside some
> > > vendors private database when that vendor doesn't want to expose any
> > > actual real information.
> >
> > What I see here is:
> >
> > 1. A valid reason to have a UUID is to help a machine that's
> > processing data.  Specifically UUIDs are well-formed and easy for a
> > machine to understand (unlike a link which could point to anything).
>
> I don't think a "link could point to anything" is a good argument
> against links. A link to lore.kernel.org/r/<message-id> should point
> to only one thing.

If everyone uses exactly "lore.kernel.org/r/<message-id>" then, yes,
that would be easy to parse.  ...but now how do you refer to this?
Let's say we have:

patch v1 0/2 - MSG-ID-A
patch v1 1/2 - MSG-ID-B
patch v1 2/2 - MSG-ID-C

patch v2 0/2 - MSG-ID-D
patch v2 1/2 - MSG-ID-E
patch v2 2/2 - MSG-ID-F

Now we want to post v3?  What exact tag do I add to my v3 messages to
point back to v2?  Should all patches in v3 contain the line:

Link: https://lore.kernel.org/r/MSG-ID-D

...and people just figure that the Link line is always automatically a
link to the cover letter of the v2?  ...or we have some new tag in
each patch?

Link-prev-version: https://lore.kernel.org/r/MSG-ID-E

What syntax are you suggesting here?  Do we point to the cover?  The
previous version?  All previous versions?  Will everyone agree on it?


> > 2. In the past you don't like UUIDs because the machines making sense
> > of them are private.
> >
> > In this thread I am trying to argue that if we allow UUIDs in the
> > public email lists that anyone will be able to create a useful and
> > public database linking patch versions together.
>
> Did you read all the emails that said these can be inserted into the
> discardable part of a patch? Enforcing it on everyone in the community
> is impossible.

Sure, and I think I replied to them several times.  The basic summary is that:

* This requires extra tooling that I think nobody will adopt.  People
today already (accidentally) adopt Change-Id in the non-discardable
portion.  I think it would be easier to get everyone currently
removing Change-Id to start including it again than it will be to get
everyone to change their tools to move it to the discardable portion.

* I also said that earlier if Change-Id as part of the patch is
rejected (sounds like it will be) that I may start myself doing
exactly what you suggest.  AKA: putting it into the discardable part.
Of course I will likely get yelled at even for that.

* At the moment I can't think of any benefit of Change-Id in the
discardable part of the patch compared to encoding the Change-Id into
the message ID in a way that it could be extracted.


> > > In other words: UUID's are bad and pointless. Their only "valid" use
> > > is explicitly against the whole point of open development.
> > >
> > > Use an actual open standard instead: a web link. It can be anything.
> >
> > The "It can be anything" is the problem with links.  Computers trying
>
> I think he meant it can be any link. But what a link points to
> (lore.kernel.org/r/<message-id>) largely should not change.
>
> > NOTE: from reading all of this, one thing that I should probably be
> > able to do myself is:
> >
> > 1. Keep having Change-Id in my patches on my local computer.
> >
> > 2. Have the scripts I use to post upstream (which strips Change-Id out
> > before posting) encode the Change-Id into the Message-Id in a way that
> > it could be recovered, like:
> >
> > Message-Id: Ic3e54798e4aeaa862b2e8eebcbbcef4e51ccae19-2018-1231-235959-1
>
> Why not just put whatever-ID in the discardable part of your patch as
> others have also pointed, and move on?

1. I can guarantee that someone will yell at me for it despite it
being in the discardable part.  Without some sort of official policy
(or mailing list thread) that this is acceptable or even encouraged
then individual maintainers will not like it even in the discardable
portion.

2. I believe it requires roughly the same amount of tooling to put it
in the Message-Id compared to putting it into the discardable portion
of the patch.

3. Everyone keeps repeating that since we have Message-Id we don't
need another UUID.  Even in the discardable portion of the patch
Change-Id is just another UUID.


-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 21:35                                         ` Doug Anderson
@ 2019-08-26 21:51                                           ` Thomas Gleixner
  2019-08-26 22:06                                             ` Doug Anderson
  2019-08-26 23:02                                           ` Theodore Y. Ts'o
  1 sibling, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-26 21:51 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Mon, 26 Aug 2019, Doug Anderson wrote:
> On Mon, Aug 26, 2019 at 10:31 AM Joel Fernandes <joelaf@google.com> wrote:
> * At the moment I can't think of any benefit of Change-Id in the
> discardable part of the patch compared to encoding the Change-Id into
> the message ID in a way that it could be extracted.

What prevents you from munging your change-id into the message id?

As long as the resulting message ids of your v1..vn series are unique, the
lore link which we want to have inserted automatically works and so does
your change id tracking.

Most people wont even notice that you do that unless you mess up and break
the uniqueness.
 
Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-25  7:09                                     ` Thomas Gleixner
@ 2019-08-26 22:05                                       ` Thomas Gleixner
  2019-08-28  8:50                                         ` Thomas Gleixner
  0 siblings, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-26 22:05 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

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

On Sun, 25 Aug 2019, Thomas Gleixner wrote:
> On Sat, 24 Aug 2019, Theodore Y. Ts'o wrote:
> > I use quilt for processing incoming changes for ext4 as well; would
> > you mind sharing your script?  This sounds like it would be really
> > useful for me.
> 
> Sure. Give me a day or two to make it less embarrassing by removing the
> duct tape it grew over time. :)

So I found some spare time and refactored the pile to something halfways
sane. Real snake programmers will probably still run away screaming :)

Right now there is only the mb2q utility in there, but I want to add some
more of my stuff over time.

During the rework I switched it over to python3 only as I now use some of
the new pyhton3 only email conveniance functionality. email is a pain in
general but even more so in python2. The tool is a standalone script and
requires only python3-yaml which should be packaged on most distros.

To make this even useful for non quilt users, I added a command line option
which allows to create a mailbox instead of a quilt series. The resulting
mailbox is formatted in the same way as the quilt series with tags
collected, etc. That generate mailbox can be directly applied with git-am.

For details see the man page / html documentation.

It's not perfect, but it works for the usual patch submission mail
threads. I occacionally have to do some manual fixup for special cases, but
I can't be bothered to automate them further.

Documentation/examples has a template for a config file, but mb2q has
(hopefully) sane defaults and should even work without. But the config file
can be used to do customization especially if you deal with different lists
and projects. You can have multiple and override the default location on
the command line.

As I did not get a repo set up on git.kernel.org for this yet, find
attached a git bundle which allows you to clone my repo for now. That works
like a regular clone

  $ git clone /path/to/stored/attachement/quilttools

Once our helpful friends at k.org have set up the repo I asked for, I'll
push it out and you can switch the origin over from the bundle.

I hope this is helpful and if you find bugs, you know where to send the
patches to :)

Thanks,

	tglx

[-- Attachment #2: Type: application/octet-stream, Size: 21875 bytes --]

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 21:51                                           ` Thomas Gleixner
@ 2019-08-26 22:06                                             ` Doug Anderson
  2019-08-26 22:19                                               ` Thomas Gleixner
  0 siblings, 1 reply; 105+ messages in thread
From: Doug Anderson @ 2019-08-26 22:06 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi,

On Mon, Aug 26, 2019 at 2:51 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Mon, 26 Aug 2019, Doug Anderson wrote:
> > On Mon, Aug 26, 2019 at 10:31 AM Joel Fernandes <joelaf@google.com> wrote:
> > * At the moment I can't think of any benefit of Change-Id in the
> > discardable part of the patch compared to encoding the Change-Id into
> > the message ID in a way that it could be extracted.
>
> What prevents you from munging your change-id into the message id?
>
> As long as the resulting message ids of your v1..vn series are unique, the
> lore link which we want to have inserted automatically works and so does
> your change id tracking.
>
> Most people wont even notice that you do that unless you mess up and break
> the uniqueness.

Right.  This is exactly what I was trying to say in my post, but
apparently I failed at it.  In case it helps to reiterate my current
plan:

1. If some magic happens and folks suddenly embrace Change-Id as part
of the patch then I'll be happy because I think adoption will be
higher.

2. If, as I expect, Change-Id as part of the patch stays NAKed then I
will modify the tools I use to post upstream (currently patman) to
encode the Change-Id.  My naive proposal would be:

Message-Id: ChangeId-YYYY-MMDD-HHMMSS-PatchNum

If I try this and it works for me then I will post out and suggest
that any other like-minded people encode Change-Id into Message-Id in
a similar way.

-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 22:06                                             ` Doug Anderson
@ 2019-08-26 22:19                                               ` Thomas Gleixner
  0 siblings, 0 replies; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-26 22:19 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Mon, 26 Aug 2019, Doug Anderson wrote:
> 2. If, as I expect, Change-Id as part of the patch stays NAKed then I
> will modify the tools I use to post upstream (currently patman) to
> encode the Change-Id.  My naive proposal would be:
> 
> Message-Id: ChangeId-YYYY-MMDD-HHMMSS-PatchNum

Please use one of the library functions of your language of choice and do
not construct it yourself. My pain with malformatted email headers is
already big enough.

Python:

   id = '%s.%s' %(changeid, email.utils.make_msgid())

   id = email.utils.make_msgid(changeid)

Depending on where you want to have it positioned, which does not actually
matter :)

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-23  3:03             ` Linus Torvalds
  2019-08-23 13:15               ` Sean Paul
  2019-08-23 18:10               ` Konstantin Ryabitsev
@ 2019-08-26 22:19               ` Paul Mackerras
  2019-08-27  7:02                 ` Stephen Rothwell
  2 siblings, 1 reply; 105+ messages in thread
From: Paul Mackerras @ 2019-08-26 22:19 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Thu, Aug 22, 2019 at 08:03:51PM -0700, Linus Torvalds wrote:
> On Thu, Aug 22, 2019 at 7:58 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So yes, I'd *much* rather see that "Link" line than try to make a
> > "Change-ID" line be a thing.
> 
> Tangential note: since it looks like "Link:" lines are going to get
> more common in general, maybe somebody with the right tck/tk-fu can
> make a tool like 'gitk' be able to just do the hyperlinking thing (it
> already does it for commit hashes in the commit message, but wouldn't
> it be convenient to do that for web links too and open a browser
> tab?).

I just posted a patch to do that to the git mailing list (see
https://marc.info/?l=git&m=156685770100577&w=2).  I'll commit it after
people have had a chance to comment on the regexp for detecting links
and the choice of web browser command for each platform.

Paul.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 21:35                                         ` Doug Anderson
  2019-08-26 21:51                                           ` Thomas Gleixner
@ 2019-08-26 23:02                                           ` Theodore Y. Ts'o
  2019-08-26 23:11                                             ` Doug Anderson
                                                               ` (2 more replies)
  1 sibling, 3 replies; 105+ messages in thread
From: Theodore Y. Ts'o @ 2019-08-26 23:02 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Mon, Aug 26, 2019 at 02:35:33PM -0700, Doug Anderson wrote:
> * This requires extra tooling that I think nobody will adopt.  People
> today already (accidentally) adopt Change-Id in the non-discardable
> portion.  I think it would be easier to get everyone currently
> removing Change-Id to start including it again than it will be to get
> everyone to change their tools to move it to the discardable portion.

The reason why people Change-Id's exist in commits today is because of
tooling which is distributed as part of Gerrit.  That's why people are
deeply suspicious of any solution that involves Change-Id in the
non-discarded portion --- because the majority of Gerrit servers up
until now are behind corporate firewalls and since Gerrit servers have
robots.txt files, most Change-Id tend to be useless.

If we come up with new tooling which is more useful, people will use
it.  If it's not useful and doesn't makes life easier, people won't.



On Mon, Aug 26, 2019 at 03:06:43PM -0700, Doug Anderson wrote:
> 2. If, as I expect, Change-Id as part of the patch stays NAKed then I
> will modify the tools I use to post upstream (currently patman) to
> encode the Change-Id.  My naive proposal would be:
> 
> Message-Id: ChangeId-YYYY-MMDD-HHMMSS-PatchNum
> 
> If I try this and it works for me then I will post out and suggest
> that any other like-minded people encode Change-Id into Message-Id in
> a similar way.

... and I would expect patches with this would get NACK'ed because
they would be just as useless as Change-Id's are perceived to be
today.  People who are gaming the rules will tend not to looked upon
favorably; the same will apply to their patches.

BTW, the Message-Id you've listed above is not legal, per RFC-5322.  A
msg-id has to look like a e-mail address (left-hand-side@example.com).
So something like this is legal as a message id:

I3268f9036512c4378cde1da37e0612b43ed4d384@linux-review.googlesource.com

... and indeed, that's more useful, because it tells us how to
interpret I3268f9036512c4378cde1da37e0612b43ed4d384 --- it's a
Change-Id assigned by the linux-review.googlesource.com Gerrit server.

In contrast a bare "I3268f9036512c4378cde1da37e0612b43ed4d384" is
going to be presumed to be useless.  And in fact, a Google search for
this ID returns *nothing*.  Yet visiting the link
https://linux-review.googlesource.com/c/1158 actually returns
something useful.   That's why the latter is superior to the former.

In summary,

Not useful: (and will be probably nacked)

Change-Id: I3268f9036512c4378cde1da37e0612b43ed4d384
Message-Id: I3268f9036512c4378cde1da37e0612b43ed4d384

Useful:

Link: https://linux-review.googlesource.com/c/1158
Link: https://lkml.kernel.org/r/20190826204407.17759-1-daniel.lezcano@linaro.org

Not as useful: (people will prefer the Link example above)

Message-Id: 20190826204407.17759-1-daniel.lezcano@linaro.org

						- Ted

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 23:02                                           ` Theodore Y. Ts'o
@ 2019-08-26 23:11                                             ` Doug Anderson
  2019-09-16 14:11                                               ` Christian Brauner
  2019-09-16 17:43                                               ` Al Viro
  2019-08-26 23:43                                             ` Thomas Gleixner
  2019-08-27  0:29                                             ` Dmitry Vyukov
  2 siblings, 2 replies; 105+ messages in thread
From: Doug Anderson @ 2019-08-26 23:11 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi,

On Mon, Aug 26, 2019 at 4:02 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Mon, Aug 26, 2019 at 02:35:33PM -0700, Doug Anderson wrote:
> > * This requires extra tooling that I think nobody will adopt.  People
> > today already (accidentally) adopt Change-Id in the non-discardable
> > portion.  I think it would be easier to get everyone currently
> > removing Change-Id to start including it again than it will be to get
> > everyone to change their tools to move it to the discardable portion.
>
> The reason why people Change-Id's exist in commits today is because of
> tooling which is distributed as part of Gerrit.  That's why people are
> deeply suspicious of any solution that involves Change-Id in the
> non-discarded portion --- because the majority of Gerrit servers up
> until now are behind corporate firewalls and since Gerrit servers have
> robots.txt files, most Change-Id tend to be useless.
>
> If we come up with new tooling which is more useful, people will use
> it.  If it's not useful and doesn't makes life easier, people won't.

Unfortunately the tooling won't come up until Change-Id is there and
Change-Id can't be there till the tooling is there.  ;-)


> On Mon, Aug 26, 2019 at 03:06:43PM -0700, Doug Anderson wrote:
> > 2. If, as I expect, Change-Id as part of the patch stays NAKed then I
> > will modify the tools I use to post upstream (currently patman) to
> > encode the Change-Id.  My naive proposal would be:
> >
> > Message-Id: ChangeId-YYYY-MMDD-HHMMSS-PatchNum
> >
> > If I try this and it works for me then I will post out and suggest
> > that any other like-minded people encode Change-Id into Message-Id in
> > a similar way.
>
> ... and I would expect patches with this would get NACK'ed because
> they would be just as useless as Change-Id's are perceived to be
> today.  People who are gaming the rules will tend not to looked upon
> favorably; the same will apply to their patches.

Sigh.  Email is so hard to communicate over.  I'm not intending to
include the Message-Id in the commit.  I'm intending to use the
Change-Id _in_ the Message-Id.  The Message-Id already has a bunch of
random characters in it.  Why not make them useful for something?


> BTW, the Message-Id you've listed above is not legal, per RFC-5322.  A
> msg-id has to look like a e-mail address (left-hand-side@example.com).
> So something like this is legal as a message id:
>
> I3268f9036512c4378cde1da37e0612b43ed4d384@linux-review.googlesource.com

I think this is the same comment that Thomas Gleixner had.  I will
certainly make sure my Message-Ids are formed correctly.  Thank you
both for pointing this out to me.  Presumably I would have noticed it
when actually trying to implement this but now I definitely will.


> ... and indeed, that's more useful, because it tells us how to
> interpret I3268f9036512c4378cde1da37e0612b43ed4d384 --- it's a
> Change-Id assigned by the linux-review.googlesource.com Gerrit server.
>
> In contrast a bare "I3268f9036512c4378cde1da37e0612b43ed4d384" is
> going to be presumed to be useless.  And in fact, a Google search for
> this ID returns *nothing*.  Yet visiting the link
> https://linux-review.googlesource.com/c/1158 actually returns
> something useful.   That's why the latter is superior to the former.

Sure, except that in my case there is no gerrit server to provide a
link to.  I use an upstream-first approach which means that all
initial work is done with mailing lists.  There is no server to
provide context to.  I think we are re-hashing old emails in this
thread.


> In summary,
>
> Not useful: (and will be probably nacked)
>
> Change-Id: I3268f9036512c4378cde1da37e0612b43ed4d384
> Message-Id: I3268f9036512c4378cde1da37e0612b43ed4d384
>
> Useful:
>
> Link: https://linux-review.googlesource.com/c/1158
> Link: https://lkml.kernel.org/r/20190826204407.17759-1-daniel.lezcano@linaro.org
>
> Not as useful: (people will prefer the Link example above)
>
> Message-Id: 20190826204407.17759-1-daniel.lezcano@linaro.org

Presumably all the above is because you thought I was including the
Message-Id in the commit.  I'm not.  Locally I will have Change-Id in
my commit.  The scripts I use to post to the mailing lists will strip
the Change-Id out and use it to make the actual Message-Id.  I will
make sure that the Message ID is well formed.

-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 23:02                                           ` Theodore Y. Ts'o
  2019-08-26 23:11                                             ` Doug Anderson
@ 2019-08-26 23:43                                             ` Thomas Gleixner
  2019-08-28 12:34                                               ` Christian Brauner
  2019-08-27  0:29                                             ` Dmitry Vyukov
  2 siblings, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-26 23:43 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Mon, 26 Aug 2019, Theodore Y. Ts'o wrote:
> On Mon, Aug 26, 2019 at 03:06:43PM -0700, Doug Anderson wrote:
> > 2. If, as I expect, Change-Id as part of the patch stays NAKed then I
> > will modify the tools I use to post upstream (currently patman) to
> > encode the Change-Id.  My naive proposal would be:
> > 
> > Message-Id: ChangeId-YYYY-MMDD-HHMMSS-PatchNum
> > 
> > If I try this and it works for me then I will post out and suggest
> > that any other like-minded people encode Change-Id into Message-Id in
> > a similar way.
> 
> ... and I would expect patches with this would get NACK'ed because
> they would be just as useless as Change-Id's are perceived to be
> today.  People who are gaming the rules will tend not to looked upon
> favorably; the same will apply to their patches.
> 
> BTW, the Message-Id you've listed above is not legal, per RFC-5322.  A
> msg-id has to look like a e-mail address (left-hand-side@example.com).
> So something like this is legal as a message id:
> 
> I3268f9036512c4378cde1da37e0612b43ed4d384@linux-review.googlesource.com
> 
> ... and indeed, that's more useful, because it tells us how to
> interpret I3268f9036512c4378cde1da37e0612b43ed4d384 --- it's a
> Change-Id assigned by the linux-review.googlesource.com Gerrit server.
> 
> In contrast a bare "I3268f9036512c4378cde1da37e0612b43ed4d384" is
> going to be presumed to be useless.  And in fact, a Google search for
> this ID returns *nothing*.  Yet visiting the link
> https://linux-review.googlesource.com/c/1158 actually returns
> something useful.   That's why the latter is superior to the former.

That's fine, but the point is that nobody will prevent you from frobbing
your message-id's in a way which encodes other information into it as long
as the message-id is RFC compliant. We simply don't care because the result
is just a message-id as any other in the mail header of your patch
submission,

I agree that a full gerrit link is more useful, but what Doug described is
not connected to a gerrit server at all. He just (ab)uses the tooling which
allows him to create a unique ID to track versions of his patches.

Actually not the worst idea. If the result is not part of the changelog and
just part of the email then generating the id with

     id = make_msgid(ChangeId)

will still generate something useful for everyone because we can add:

     Link: https://lore.kernel.org/lkml/$id

and Doug can grep the archives for $id.

I truly don't care whether the Message-ID header contains extra information
as long as it is properly formatted.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 23:02                                           ` Theodore Y. Ts'o
  2019-08-26 23:11                                             ` Doug Anderson
  2019-08-26 23:43                                             ` Thomas Gleixner
@ 2019-08-27  0:29                                             ` Dmitry Vyukov
  2019-08-27  6:06                                               ` Thomas Gleixner
  2019-08-27  7:33                                               ` Geert Uytterhoeven
  2 siblings, 2 replies; 105+ messages in thread
From: Dmitry Vyukov @ 2019-08-27  0:29 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov

On Mon, Aug 26, 2019 at 4:02 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Mon, Aug 26, 2019 at 02:35:33PM -0700, Doug Anderson wrote:
> > * This requires extra tooling that I think nobody will adopt.  People
> > today already (accidentally) adopt Change-Id in the non-discardable
> > portion.  I think it would be easier to get everyone currently
> > removing Change-Id to start including it again than it will be to get
> > everyone to change their tools to move it to the discardable portion.
>
> The reason why people Change-Id's exist in commits today is because of
> tooling which is distributed as part of Gerrit.  That's why people are
> deeply suspicious of any solution that involves Change-Id in the
> non-discarded portion --- because the majority of Gerrit servers up
> until now are behind corporate firewalls and since Gerrit servers have
> robots.txt files, most Change-Id tend to be useless.
>
> If we come up with new tooling which is more useful, people will use
> it.  If it's not useful and doesn't makes life easier, people won't.
>
>
>
> On Mon, Aug 26, 2019 at 03:06:43PM -0700, Doug Anderson wrote:
> > 2. If, as I expect, Change-Id as part of the patch stays NAKed then I
> > will modify the tools I use to post upstream (currently patman) to
> > encode the Change-Id.  My naive proposal would be:
> >
> > Message-Id: ChangeId-YYYY-MMDD-HHMMSS-PatchNum
> >
> > If I try this and it works for me then I will post out and suggest
> > that any other like-minded people encode Change-Id into Message-Id in
> > a similar way.
>
> ... and I would expect patches with this would get NACK'ed because
> they would be just as useless as Change-Id's are perceived to be
> today.  People who are gaming the rules will tend not to looked upon
> favorably; the same will apply to their patches.
>
> BTW, the Message-Id you've listed above is not legal, per RFC-5322.  A
> msg-id has to look like a e-mail address (left-hand-side@example.com).
> So something like this is legal as a message id:
>
> I3268f9036512c4378cde1da37e0612b43ed4d384@linux-review.googlesource.com
>
> ... and indeed, that's more useful, because it tells us how to
> interpret I3268f9036512c4378cde1da37e0612b43ed4d384 --- it's a
> Change-Id assigned by the linux-review.googlesource.com Gerrit server.
>
> In contrast a bare "I3268f9036512c4378cde1da37e0612b43ed4d384" is
> going to be presumed to be useless.  And in fact, a Google search for
> this ID returns *nothing*.  Yet visiting the link
> https://linux-review.googlesource.com/c/1158 actually returns
> something useful.   That's why the latter is superior to the former.
>
> In summary,
>
> Not useful: (and will be probably nacked)
>
> Change-Id: I3268f9036512c4378cde1da37e0612b43ed4d384
> Message-Id: I3268f9036512c4378cde1da37e0612b43ed4d384
>
> Useful:
>
> Link: https://linux-review.googlesource.com/c/1158
> Link: https://lkml.kernel.org/r/20190826204407.17759-1-daniel.lezcano@linaro.org
>
> Not as useful: (people will prefer the Link example above)
>
> Message-Id: 20190826204407.17759-1-daniel.lezcano@linaro.org


Hi,

A somewhat related point re UUID/Change-ID.
For syzbot (or any other bug tracking system) we want to associate
bugs with fixes. It turned out there is no good identity of a change
that we could use. Commit hash is an obvious first thing to consider,
but (1) it changes in linux-next, (2) sometimes the change is not
committed yet when we do the association, (3) it is different when
backported to LTS (so not possible to say if a fix is in that stable
tree or not).
We decided to use commit subject, which works to some degree, but also
has problems: (1) not necessary unique, (2) sometimes people change
subject during backporting (e.g. prepend some prefix), (3) has all the
same problems of email clients messing with text (e.g. I can't issue
#syz fix command for loo long commit subjects with my email client).
Some real UUID/Change-ID would solve all of these problems by giving
us capability to refer to changes rather than a commit in a particular
tree only.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27  0:29                                             ` Dmitry Vyukov
@ 2019-08-27  6:06                                               ` Thomas Gleixner
  2019-08-27 13:24                                                 ` Dmitry Vyukov
  2019-08-27  7:33                                               ` Geert Uytterhoeven
  1 sibling, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-27  6:06 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov

On Mon, 26 Aug 2019, Dmitry Vyukov wrote:
> A somewhat related point re UUID/Change-ID.
> For syzbot (or any other bug tracking system) we want to associate
> bugs with fixes. It turned out there is no good identity of a change
> that we could use. Commit hash is an obvious first thing to consider,
> but (1) it changes in linux-next, (2) sometimes the change is not
> committed yet when we do the association, (3) it is different when
> backported to LTS (so not possible to say if a fix is in that stable
> tree or not).
> We decided to use commit subject, which works to some degree, but also
> has problems: (1) not necessary unique, (2) sometimes people change
> subject during backporting (e.g. prepend some prefix), (3) has all the
> same problems of email clients messing with text (e.g. I can't issue
> #syz fix command for loo long commit subjects with my email client).
> Some real UUID/Change-ID would solve all of these problems by giving
> us capability to refer to changes rather than a commit in a particular
> tree only.

If we adopt the Link: ..../$MSG tag widely then you have a UUID.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 22:19               ` Paul Mackerras
@ 2019-08-27  7:02                 ` Stephen Rothwell
  0 siblings, 0 replies; 105+ messages in thread
From: Stephen Rothwell @ 2019-08-27  7:02 UTC (permalink / raw)
  To: Paul Mackerras
  Cc: Joel Fernandes, Barret Rhoden, Dmitry Torokhov, ksummit,
	Greg Kroah-Hartman, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Vyukov

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

Hi Paul,

On Tue, 27 Aug 2019 08:19:49 +1000 Paul Mackerras <paulus@ozlabs.org> wrote:
>
> On Thu, Aug 22, 2019 at 08:03:51PM -0700, Linus Torvalds wrote:
> > On Thu, Aug 22, 2019 at 7:58 PM Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:  
> > >
> > > So yes, I'd *much* rather see that "Link" line than try to make a
> > > "Change-ID" line be a thing.  
> > 
> > Tangential note: since it looks like "Link:" lines are going to get
> > more common in general, maybe somebody with the right tck/tk-fu can
> > make a tool like 'gitk' be able to just do the hyperlinking thing (it
> > already does it for commit hashes in the commit message, but wouldn't
> > it be convenient to do that for web links too and open a browser
> > tab?).  
> 
> I just posted a patch to do that to the git mailing list (see
> https://marc.info/?l=git&m=156685770100577&w=2).  I'll commit it after
> people have had a chance to comment on the regexp for detecting links
> and the choice of web browser command for each platform.

Looks good here.  And saves me the pain of relearning enough Tcl to do
the patch myself :-)

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27  0:29                                             ` Dmitry Vyukov
  2019-08-27  6:06                                               ` Thomas Gleixner
@ 2019-08-27  7:33                                               ` Geert Uytterhoeven
  2019-08-27 13:30                                                 ` Dmitry Vyukov
  1 sibling, 1 reply; 105+ messages in thread
From: Geert Uytterhoeven @ 2019-08-27  7:33 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov

Hi Dmitry,

On Tue, Aug 27, 2019 at 2:30 AM Dmitry Vyukov via Ksummit-discuss
<ksummit-discuss@lists.linuxfoundation.org> wrote:
> A somewhat related point re UUID/Change-ID.
> For syzbot (or any other bug tracking system) we want to associate
> bugs with fixes. It turned out there is no good identity of a change
> that we could use. Commit hash is an obvious first thing to consider,
> but (1) it changes in linux-next, (2) sometimes the change is not
> committed yet when we do the association, (3) it is different when
> backported to LTS (so not possible to say if a fix is in that stable
> tree or not).

For (3): LTS commits have "commit <sha1> upstream" in their description
(perhaps some have "cherry picked from commit <sha1>"?).

> We decided to use commit subject, which works to some degree, but also
> has problems: (1) not necessary unique, (2) sometimes people change
> subject during backporting (e.g. prepend some prefix), (3) has all the
> same problems of email clients messing with text (e.g. I can't issue
> #syz fix command for loo long commit subjects with my email client).
> Some real UUID/Change-ID would solve all of these problems by giving
> us capability to refer to changes rather than a commit in a particular
> tree only.

"git patch-id --stable <sha1>" may help, too.

For quick lookups, you need to generate/append to an index regularly.

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] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-25  3:11                                       ` Greg Kroah-Hartman
@ 2019-08-27 10:51                                         ` Mark Brown
  2019-09-09  8:14                                           ` Michael Ellerman
  0 siblings, 1 reply; 105+ messages in thread
From: Mark Brown @ 2019-08-27 10:51 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

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

On Sun, Aug 25, 2019 at 05:11:43AM +0200, Greg Kroah-Hartman wrote:

> When accepting patches from people, my old scripts used to do this
> properly and reply to the sent message-id.  Now that I use git, that's
> lost, except that I now am generating Link: tags in the commit message
> itself, like:
> 	Link: https://lore.kernel.org/r/20190822213659.5501-1-hsiangkao@aol.com

> Hm, I guess I do now keep that info, and I can fix my scripts to
> properly thread things, let me go work on that later today...

What I'm doing for this is that when I apply the patch I save a
git note with the message ID and various other things then when I
push the patch out and generate the "applied, thanks" e-mail I
look for the git note and use that.  My script can also fall back
to patchwork for the lookup but it's not 100% reliable and
greatly increases the network access needs.

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27  6:06                                               ` Thomas Gleixner
@ 2019-08-27 13:24                                                 ` Dmitry Vyukov
  2019-08-27 13:48                                                   ` Greg Kroah-Hartman
  2019-08-27 14:06                                                   ` Thomas Gleixner
  0 siblings, 2 replies; 105+ messages in thread
From: Dmitry Vyukov @ 2019-08-27 13:24 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov

On Mon, Aug 26, 2019 at 11:06 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Mon, 26 Aug 2019, Dmitry Vyukov wrote:
> > A somewhat related point re UUID/Change-ID.
> > For syzbot (or any other bug tracking system) we want to associate
> > bugs with fixes. It turned out there is no good identity of a change
> > that we could use. Commit hash is an obvious first thing to consider,
> > but (1) it changes in linux-next, (2) sometimes the change is not
> > committed yet when we do the association, (3) it is different when
> > backported to LTS (so not possible to say if a fix is in that stable
> > tree or not).
> > We decided to use commit subject, which works to some degree, but also
> > has problems: (1) not necessary unique, (2) sometimes people change
> > subject during backporting (e.g. prepend some prefix), (3) has all the
> > same problems of email clients messing with text (e.g. I can't issue
> > #syz fix command for loo long commit subjects with my email client).
> > Some real UUID/Change-ID would solve all of these problems by giving
> > us capability to refer to changes rather than a commit in a particular
> > tree only.
>
> If we adopt the Link: ..../$MSG tag widely then you have a UUID.

Is there a way to ensure that everybody will generate right IDs
(ChangeID-Version) and then a link in canonical form will be included
into commit? As far as I understand this is not possible with the
current kernel tooling, as this aspect is not under control of any
unified tooling.
I see different maintainers use links to different archive web sites.
Also sometimes Link is present for other reasons (e.g. link to bug
report).
The link will need to be added by every developer (rather than
maintainer) so that it's available before the change is committed
anywhere.
Though, most of these are problems for any other change identification scheme...

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27  7:33                                               ` Geert Uytterhoeven
@ 2019-08-27 13:30                                                 ` Dmitry Vyukov
  2019-08-27 14:28                                                   ` Paul E. McKenney
  0 siblings, 1 reply; 105+ messages in thread
From: Dmitry Vyukov @ 2019-08-27 13:30 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov

On Tue, Aug 27, 2019 at 12:33 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Dmitry,
>
> On Tue, Aug 27, 2019 at 2:30 AM Dmitry Vyukov via Ksummit-discuss
> <ksummit-discuss@lists.linuxfoundation.org> wrote:
> > A somewhat related point re UUID/Change-ID.
> > For syzbot (or any other bug tracking system) we want to associate
> > bugs with fixes. It turned out there is no good identity of a change
> > that we could use. Commit hash is an obvious first thing to consider,
> > but (1) it changes in linux-next, (2) sometimes the change is not
> > committed yet when we do the association, (3) it is different when
> > backported to LTS (so not possible to say if a fix is in that stable
> > tree or not).
>
> For (3): LTS commits have "commit <sha1> upstream" in their description
> (perhaps some have "cherry picked from commit <sha1>"?).

A change identification scheme would need to solve all of these. E.g.
non-committed changes look more problematic for anything that uses
commit hashes...

> > We decided to use commit subject, which works to some degree, but also
> > has problems: (1) not necessary unique, (2) sometimes people change
> > subject during backporting (e.g. prepend some prefix), (3) has all the
> > same problems of email clients messing with text (e.g. I can't issue
> > #syz fix command for loo long commit subjects with my email client).
> > Some real UUID/Change-ID would solve all of these problems by giving
> > us capability to refer to changes rather than a commit in a particular
> > tree only.
>
> "git patch-id --stable <sha1>" may help, too.
>
> For quick lookups, you need to generate/append to an index regularly.

It's not me, it's everybody ;)
If I am reading git help correctly, this won't handle changes with
more than 1 version. Also maintainers will be prohibited from doing
any changed to patches during commit.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 13:24                                                 ` Dmitry Vyukov
@ 2019-08-27 13:48                                                   ` Greg Kroah-Hartman
  2019-08-27 14:01                                                     ` Guenter Roeck
  2019-08-27 14:06                                                   ` Thomas Gleixner
  1 sibling, 1 reply; 105+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-27 13:48 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov

On Tue, Aug 27, 2019 at 06:24:36AM -0700, Dmitry Vyukov wrote:
> On Mon, Aug 26, 2019 at 11:06 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > On Mon, 26 Aug 2019, Dmitry Vyukov wrote:
> > > A somewhat related point re UUID/Change-ID.
> > > For syzbot (or any other bug tracking system) we want to associate
> > > bugs with fixes. It turned out there is no good identity of a change
> > > that we could use. Commit hash is an obvious first thing to consider,
> > > but (1) it changes in linux-next, (2) sometimes the change is not
> > > committed yet when we do the association, (3) it is different when
> > > backported to LTS (so not possible to say if a fix is in that stable
> > > tree or not).
> > > We decided to use commit subject, which works to some degree, but also
> > > has problems: (1) not necessary unique, (2) sometimes people change
> > > subject during backporting (e.g. prepend some prefix), (3) has all the
> > > same problems of email clients messing with text (e.g. I can't issue
> > > #syz fix command for loo long commit subjects with my email client).
> > > Some real UUID/Change-ID would solve all of these problems by giving
> > > us capability to refer to changes rather than a commit in a particular
> > > tree only.
> >
> > If we adopt the Link: ..../$MSG tag widely then you have a UUID.
> 
> Is there a way to ensure that everybody will generate right IDs
> (ChangeID-Version) and then a link in canonical form will be included
> into commit? As far as I understand this is not possible with the
> current kernel tooling, as this aspect is not under control of any
> unified tooling.
> I see different maintainers use links to different archive web sites.
> Also sometimes Link is present for other reasons (e.g. link to bug
> report).
> The link will need to be added by every developer (rather than
> maintainer) so that it's available before the change is committed
> anywhere.

For subsystems I maintain, I am already adding the Link: tag to
lore.kernel.org with the message id in it.  That is automatically added
by my scripts.

> Though, most of these are problems for any other change identification scheme...

Note, we have 4000+ developers every year, it's hard enough to get them
all to agree on major things, let alone crazy stuff like this :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 13:48                                                   ` Greg Kroah-Hartman
@ 2019-08-27 14:01                                                     ` Guenter Roeck
  2019-08-27 14:09                                                       ` Thomas Gleixner
  2019-08-27 17:34                                                       ` Geert Uytterhoeven
  0 siblings, 2 replies; 105+ messages in thread
From: Guenter Roeck @ 2019-08-27 14:01 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Dmitry Vyukov
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov

On 8/27/19 6:48 AM, Greg Kroah-Hartman wrote:
> On Tue, Aug 27, 2019 at 06:24:36AM -0700, Dmitry Vyukov wrote:
>> On Mon, Aug 26, 2019 at 11:06 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>>>
>>> On Mon, 26 Aug 2019, Dmitry Vyukov wrote:
>>>> A somewhat related point re UUID/Change-ID.
>>>> For syzbot (or any other bug tracking system) we want to associate
>>>> bugs with fixes. It turned out there is no good identity of a change
>>>> that we could use. Commit hash is an obvious first thing to consider,
>>>> but (1) it changes in linux-next, (2) sometimes the change is not
>>>> committed yet when we do the association, (3) it is different when
>>>> backported to LTS (so not possible to say if a fix is in that stable
>>>> tree or not).
>>>> We decided to use commit subject, which works to some degree, but also
>>>> has problems: (1) not necessary unique, (2) sometimes people change
>>>> subject during backporting (e.g. prepend some prefix), (3) has all the
>>>> same problems of email clients messing with text (e.g. I can't issue
>>>> #syz fix command for loo long commit subjects with my email client).
>>>> Some real UUID/Change-ID would solve all of these problems by giving
>>>> us capability to refer to changes rather than a commit in a particular
>>>> tree only.
>>>
>>> If we adopt the Link: ..../$MSG tag widely then you have a UUID.
>>
>> Is there a way to ensure that everybody will generate right IDs
>> (ChangeID-Version) and then a link in canonical form will be included
>> into commit? As far as I understand this is not possible with the
>> current kernel tooling, as this aspect is not under control of any
>> unified tooling.
>> I see different maintainers use links to different archive web sites.
>> Also sometimes Link is present for other reasons (e.g. link to bug
>> report).
>> The link will need to be added by every developer (rather than
>> maintainer) so that it's available before the change is committed
>> anywhere.
> 
> For subsystems I maintain, I am already adding the Link: tag to
> lore.kernel.org with the message id in it.  That is automatically added
> by my scripts.
> 
>> Though, most of these are problems for any other change identification scheme...
> 
> Note, we have 4000+ developers every year, it's hard enough to get them
> all to agree on major things, let alone crazy stuff like this :)
> 

Is it really that crazy ?

I have to use a combination of subject analysis and patch content analysis
using fuzzy text / string comparison, combined with an analysis of the patch
description, to answer a simple question: Is this patch upstream, and what is
its upstream SHA ? Having a UUID tag would make this a simple and
straightforward operation. What is crazy is having to do all this analysis.

Guenter

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 13:24                                                 ` Dmitry Vyukov
  2019-08-27 13:48                                                   ` Greg Kroah-Hartman
@ 2019-08-27 14:06                                                   ` Thomas Gleixner
  1 sibling, 0 replies; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-27 14:06 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov

On Tue, 27 Aug 2019, Dmitry Vyukov wrote:

> On Mon, Aug 26, 2019 at 11:06 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > On Mon, 26 Aug 2019, Dmitry Vyukov wrote:
> > > A somewhat related point re UUID/Change-ID.
> > > For syzbot (or any other bug tracking system) we want to associate
> > > bugs with fixes. It turned out there is no good identity of a change
> > > that we could use. Commit hash is an obvious first thing to consider,
> > > but (1) it changes in linux-next, (2) sometimes the change is not
> > > committed yet when we do the association, (3) it is different when
> > > backported to LTS (so not possible to say if a fix is in that stable
> > > tree or not).
> > > We decided to use commit subject, which works to some degree, but also
> > > has problems: (1) not necessary unique, (2) sometimes people change
> > > subject during backporting (e.g. prepend some prefix), (3) has all the
> > > same problems of email clients messing with text (e.g. I can't issue
> > > #syz fix command for loo long commit subjects with my email client).
> > > Some real UUID/Change-ID would solve all of these problems by giving
> > > us capability to refer to changes rather than a commit in a particular
> > > tree only.
> >
> > If we adopt the Link: ..../$MSG tag widely then you have a UUID.
> 
> Is there a way to ensure that everybody will generate right IDs
> (ChangeID-Version) and then a link in canonical form will be included

What? You want to enforce that on every single person on the planet who
submits patches for the kernel? Good luck with that.

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 14:01                                                     ` Guenter Roeck
@ 2019-08-27 14:09                                                       ` Thomas Gleixner
  2019-08-27 15:33                                                         ` Greg Kroah-Hartman
  2019-08-27 17:34                                                       ` Geert Uytterhoeven
  1 sibling, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-27 14:09 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Tue, 27 Aug 2019, Guenter Roeck wrote:
> On 8/27/19 6:48 AM, Greg Kroah-Hartman wrote:
> > Note, we have 4000+ developers every year, it's hard enough to get them
> > all to agree on major things, let alone crazy stuff like this :)
> > 
> 
> Is it really that crazy ?
> 
> I have to use a combination of subject analysis and patch content analysis
> using fuzzy text / string comparison, combined with an analysis of the patch
> description, to answer a simple question: Is this patch upstream, and what is
> its upstream SHA ? Having a UUID tag would make this a simple and
> straightforward operation. What is crazy is having to do all this analysis.

Again. If we agree on adding

       Link: https://lkml.kernel.org/$Message-ID

then you have your UUID tag. The tip bot sends you a reply based on that
tag and I know you got some of them already.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 13:30                                                 ` Dmitry Vyukov
@ 2019-08-27 14:28                                                   ` Paul E. McKenney
  2019-08-27 15:06                                                     ` Thomas Gleixner
  0 siblings, 1 reply; 105+ messages in thread
From: Paul E. McKenney @ 2019-08-27 14:28 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov

On Tue, Aug 27, 2019 at 06:30:11AM -0700, Dmitry Vyukov via Ksummit-discuss wrote:
> On Tue, Aug 27, 2019 at 12:33 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> >
> > Hi Dmitry,
> >
> > On Tue, Aug 27, 2019 at 2:30 AM Dmitry Vyukov via Ksummit-discuss
> > <ksummit-discuss@lists.linuxfoundation.org> wrote:
> > > A somewhat related point re UUID/Change-ID.
> > > For syzbot (or any other bug tracking system) we want to associate
> > > bugs with fixes. It turned out there is no good identity of a change
> > > that we could use. Commit hash is an obvious first thing to consider,
> > > but (1) it changes in linux-next, (2) sometimes the change is not
> > > committed yet when we do the association, (3) it is different when
> > > backported to LTS (so not possible to say if a fix is in that stable
> > > tree or not).
> >
> > For (3): LTS commits have "commit <sha1> upstream" in their description
> > (perhaps some have "cherry picked from commit <sha1>"?).
> 
> A change identification scheme would need to solve all of these. E.g.
> non-committed changes look more problematic for anything that uses
> commit hashes...
> 
> > > We decided to use commit subject, which works to some degree, but also
> > > has problems: (1) not necessary unique, (2) sometimes people change
> > > subject during backporting (e.g. prepend some prefix), (3) has all the
> > > same problems of email clients messing with text (e.g. I can't issue
> > > #syz fix command for loo long commit subjects with my email client).
> > > Some real UUID/Change-ID would solve all of these problems by giving
> > > us capability to refer to changes rather than a commit in a particular
> > > tree only.
> >
> > "git patch-id --stable <sha1>" may help, too.
> >
> > For quick lookups, you need to generate/append to an index regularly.
> 
> It's not me, it's everybody ;)
> If I am reading git help correctly, this won't handle changes with
> more than 1 version. Also maintainers will be prohibited from doing
> any changed to patches during commit.

Or we are required to add more Link: tags or other annotations describing
what we changed and why.

							Thanx, Paul

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 14:28                                                   ` Paul E. McKenney
@ 2019-08-27 15:06                                                     ` Thomas Gleixner
  2019-08-27 15:25                                                       ` Paul E. McKenney
  0 siblings, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-27 15:06 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Tue, 27 Aug 2019, Paul E. McKenney wrote:
> On Tue, Aug 27, 2019 at 06:30:11AM -0700, Dmitry Vyukov via Ksummit-discuss wrote:
> > If I am reading git help correctly, this won't handle changes with
> > more than 1 version. Also maintainers will be prohibited from doing
> > any changed to patches during commit.
> 
> Or we are required to add more Link: tags or other annotations describing
> what we changed and why.

The point is that the Link: tag connects the commit to the email by
which it was submitted.

If the committer fixes something up when committing, then this still stays
the same connection.

So you have SHA1 + Message-ID. If the SHA1 changes and Message-ID stays
then same, then either the patch was amended or rebased. But you can figure
that out with diff.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 15:06                                                     ` Thomas Gleixner
@ 2019-08-27 15:25                                                       ` Paul E. McKenney
  2019-08-28  8:57                                                         ` Dan Carpenter
  0 siblings, 1 reply; 105+ messages in thread
From: Paul E. McKenney @ 2019-08-27 15:25 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Tue, Aug 27, 2019 at 05:06:13PM +0200, Thomas Gleixner wrote:
> On Tue, 27 Aug 2019, Paul E. McKenney wrote:
> > On Tue, Aug 27, 2019 at 06:30:11AM -0700, Dmitry Vyukov via Ksummit-discuss wrote:
> > > If I am reading git help correctly, this won't handle changes with
> > > more than 1 version. Also maintainers will be prohibited from doing
> > > any changed to patches during commit.
> > 
> > Or we are required to add more Link: tags or other annotations describing
> > what we changed and why.
> 
> The point is that the Link: tag connects the commit to the email by
> which it was submitted.
> 
> If the committer fixes something up when committing, then this still stays
> the same connection.
> 
> So you have SHA1 + Message-ID. If the SHA1 changes and Message-ID stays
> then same, then either the patch was amended or rebased. But you can figure
> that out with diff.

So I "git am" a patch after running your tool, and it has "Link:".  I run
tests, find a bug, and update the commit with a fix (which admittedly
is not the normal workflow).  I can presumably keep doing what I do now:

[ paulmck: Fix blablabla due to rcutorture failure blablabla. ]

Someone then reviews the patch and reports a bug.  I update the
commit with a fix.  Now what I do is this:

[ paulmck: Update based on blablabla feedback from So And So. ]

I suppose I could add a second "Link:", which was what I was thinking
when responding to Dmitry's email.  Sounds like I continue with the
"[ paulmck: blablabla ]" approach  ;-)

							Thanx, Paul

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 14:09                                                       ` Thomas Gleixner
@ 2019-08-27 15:33                                                         ` Greg Kroah-Hartman
  2019-08-27 15:42                                                           ` Thomas Gleixner
  2019-08-27 18:55                                                           ` Konstantin Ryabitsev
  0 siblings, 2 replies; 105+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-27 15:33 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Tue, Aug 27, 2019 at 04:09:21PM +0200, Thomas Gleixner wrote:
> On Tue, 27 Aug 2019, Guenter Roeck wrote:
> > On 8/27/19 6:48 AM, Greg Kroah-Hartman wrote:
> > > Note, we have 4000+ developers every year, it's hard enough to get them
> > > all to agree on major things, let alone crazy stuff like this :)
> > > 
> > 
> > Is it really that crazy ?
> > 
> > I have to use a combination of subject analysis and patch content analysis
> > using fuzzy text / string comparison, combined with an analysis of the patch
> > description, to answer a simple question: Is this patch upstream, and what is
> > its upstream SHA ? Having a UUID tag would make this a simple and
> > straightforward operation. What is crazy is having to do all this analysis.
> 
> Again. If we agree on adding
> 
>        Link: https://lkml.kernel.org/$Message-ID
> 
> then you have your UUID tag. The tip bot sends you a reply based on that
> tag and I know you got some of them already.

I'm using:
	    Link: https://lore.kernel.org/r/$message-id

should we standardize on the lkml one instead as it's shorter?  The lore
one handles any message id that is on any mailing list it handles, is
the lkml one the same?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 15:33                                                         ` Greg Kroah-Hartman
@ 2019-08-27 15:42                                                           ` Thomas Gleixner
  2019-08-27 18:55                                                           ` Konstantin Ryabitsev
  1 sibling, 0 replies; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-27 15:42 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Tue, 27 Aug 2019, Greg Kroah-Hartman wrote:
> On Tue, Aug 27, 2019 at 04:09:21PM +0200, Thomas Gleixner wrote:
> > On Tue, 27 Aug 2019, Guenter Roeck wrote:
> > > On 8/27/19 6:48 AM, Greg Kroah-Hartman wrote:
> > > > Note, we have 4000+ developers every year, it's hard enough to get them
> > > > all to agree on major things, let alone crazy stuff like this :)
> > > > 
> > > 
> > > Is it really that crazy ?
> > > 
> > > I have to use a combination of subject analysis and patch content analysis
> > > using fuzzy text / string comparison, combined with an analysis of the patch
> > > description, to answer a simple question: Is this patch upstream, and what is
> > > its upstream SHA ? Having a UUID tag would make this a simple and
> > > straightforward operation. What is crazy is having to do all this analysis.
> > 
> > Again. If we agree on adding
> > 
> >        Link: https://lkml.kernel.org/$Message-ID
> > 
> > then you have your UUID tag. The tip bot sends you a reply based on that
> > tag and I know you got some of them already.
> 
> I'm using:
> 	    Link: https://lore.kernel.org/r/$message-id
> 
> should we standardize on the lkml one instead as it's shorter?  The lore
> one handles any message id that is on any mailing list it handles, is
> the lkml one the same?

I think they are the same. But i'm happy to switch to lore.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 14:01                                                     ` Guenter Roeck
  2019-08-27 14:09                                                       ` Thomas Gleixner
@ 2019-08-27 17:34                                                       ` Geert Uytterhoeven
  2019-08-27 18:50                                                         ` Guenter Roeck
  1 sibling, 1 reply; 105+ messages in thread
From: Geert Uytterhoeven @ 2019-08-27 17:34 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi Günter,

On Tue, Aug 27, 2019 at 4:01 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 8/27/19 6:48 AM, Greg Kroah-Hartman wrote:
> > On Tue, Aug 27, 2019 at 06:24:36AM -0700, Dmitry Vyukov wrote:
> >> On Mon, Aug 26, 2019 at 11:06 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> >>> On Mon, 26 Aug 2019, Dmitry Vyukov wrote:
> >>>> A somewhat related point re UUID/Change-ID.
> >>>> For syzbot (or any other bug tracking system) we want to associate
> >>>> bugs with fixes. It turned out there is no good identity of a change
> >>>> that we could use. Commit hash is an obvious first thing to consider,
> >>>> but (1) it changes in linux-next, (2) sometimes the change is not
> >>>> committed yet when we do the association, (3) it is different when
> >>>> backported to LTS (so not possible to say if a fix is in that stable
> >>>> tree or not).
> >>>> We decided to use commit subject, which works to some degree, but also
> >>>> has problems: (1) not necessary unique, (2) sometimes people change
> >>>> subject during backporting (e.g. prepend some prefix), (3) has all the
> >>>> same problems of email clients messing with text (e.g. I can't issue
> >>>> #syz fix command for loo long commit subjects with my email client).
> >>>> Some real UUID/Change-ID would solve all of these problems by giving
> >>>> us capability to refer to changes rather than a commit in a particular
> >>>> tree only.
> >>>
> >>> If we adopt the Link: ..../$MSG tag widely then you have a UUID.
> >>
> >> Is there a way to ensure that everybody will generate right IDs
> >> (ChangeID-Version) and then a link in canonical form will be included
> >> into commit? As far as I understand this is not possible with the
> >> current kernel tooling, as this aspect is not under control of any
> >> unified tooling.
> >> I see different maintainers use links to different archive web sites.
> >> Also sometimes Link is present for other reasons (e.g. link to bug
> >> report).
> >> The link will need to be added by every developer (rather than
> >> maintainer) so that it's available before the change is committed
> >> anywhere.
> >
> > For subsystems I maintain, I am already adding the Link: tag to
> > lore.kernel.org with the message id in it.  That is automatically added
> > by my scripts.
> >
> >> Though, most of these are problems for any other change identification scheme...
> >
> > Note, we have 4000+ developers every year, it's hard enough to get them
> > all to agree on major things, let alone crazy stuff like this :)
> >
>
> Is it really that crazy ?
>
> I have to use a combination of subject analysis and patch content analysis
> using fuzzy text / string comparison, combined with an analysis of the patch
> description, to answer a simple question: Is this patch upstream, and what is
> its upstream SHA ? Having a UUID tag would make this a simple and

I typically use "git cherry -v" to check if a patch is upstream.
Yes, this may miss a patch that was changed.  But that can be a good thing.

> straightforward operation. What is crazy is having to do all this analysis.

What happens to the UUID when a patch is split in two parts?
If a part is applied with the same UUID, that would give the false impression
that the original full patch was applied.

At least rebasing (using git rebase) your submissions against upstream will
keep the part that still hasn't been applied.

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] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 17:34                                                       ` Geert Uytterhoeven
@ 2019-08-27 18:50                                                         ` Guenter Roeck
  0 siblings, 0 replies; 105+ messages in thread
From: Guenter Roeck @ 2019-08-27 18:50 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Tue, Aug 27, 2019 at 07:34:45PM +0200, Geert Uytterhoeven wrote:
> Hi Günter,
> 
> On Tue, Aug 27, 2019 at 4:01 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > On 8/27/19 6:48 AM, Greg Kroah-Hartman wrote:
> > > On Tue, Aug 27, 2019 at 06:24:36AM -0700, Dmitry Vyukov wrote:
> > >> On Mon, Aug 26, 2019 at 11:06 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> > >>> On Mon, 26 Aug 2019, Dmitry Vyukov wrote:
> > >>>> A somewhat related point re UUID/Change-ID.
> > >>>> For syzbot (or any other bug tracking system) we want to associate
> > >>>> bugs with fixes. It turned out there is no good identity of a change
> > >>>> that we could use. Commit hash is an obvious first thing to consider,
> > >>>> but (1) it changes in linux-next, (2) sometimes the change is not
> > >>>> committed yet when we do the association, (3) it is different when
> > >>>> backported to LTS (so not possible to say if a fix is in that stable
> > >>>> tree or not).
> > >>>> We decided to use commit subject, which works to some degree, but also
> > >>>> has problems: (1) not necessary unique, (2) sometimes people change
> > >>>> subject during backporting (e.g. prepend some prefix), (3) has all the
> > >>>> same problems of email clients messing with text (e.g. I can't issue
> > >>>> #syz fix command for loo long commit subjects with my email client).
> > >>>> Some real UUID/Change-ID would solve all of these problems by giving
> > >>>> us capability to refer to changes rather than a commit in a particular
> > >>>> tree only.
> > >>>
> > >>> If we adopt the Link: ..../$MSG tag widely then you have a UUID.
> > >>
> > >> Is there a way to ensure that everybody will generate right IDs
> > >> (ChangeID-Version) and then a link in canonical form will be included
> > >> into commit? As far as I understand this is not possible with the
> > >> current kernel tooling, as this aspect is not under control of any
> > >> unified tooling.
> > >> I see different maintainers use links to different archive web sites.
> > >> Also sometimes Link is present for other reasons (e.g. link to bug
> > >> report).
> > >> The link will need to be added by every developer (rather than
> > >> maintainer) so that it's available before the change is committed
> > >> anywhere.
> > >
> > > For subsystems I maintain, I am already adding the Link: tag to
> > > lore.kernel.org with the message id in it.  That is automatically added
> > > by my scripts.
> > >
> > >> Though, most of these are problems for any other change identification scheme...
> > >
> > > Note, we have 4000+ developers every year, it's hard enough to get them
> > > all to agree on major things, let alone crazy stuff like this :)
> > >
> >
> > Is it really that crazy ?
> >
> > I have to use a combination of subject analysis and patch content analysis
> > using fuzzy text / string comparison, combined with an analysis of the patch
> > description, to answer a simple question: Is this patch upstream, and what is
> > its upstream SHA ? Having a UUID tag would make this a simple and
> 
> I typically use "git cherry -v" to check if a patch is upstream.
> Yes, this may miss a patch that was changed.  But that can be a good thing.
> 

I use that as well, as "first line of defense". But it doesn't always work,
for example if a patch was applied to a downstream branch while its 
upstream review was still going on, or for backports which required
conflict resolutions or context changes.

> > straightforward operation. What is crazy is having to do all this analysis.
> 
> What happens to the UUID when a patch is split in two parts?
> If a part is applied with the same UUID, that would give the false impression
> that the original full patch was applied.
> 

Presumably one would/should drop the original UUID in such a situation.
One should also not blindly trust a uuid and also perform an automated
and/or manual review. The key would be to have the ability to identify
a patch without having to search through all of them.

In practice, I use a fuzzy match on the patch subject today, followed
by another fuzzy match on the patch content. Both are expensive, even
with parallel search, especially if one has to search through 100k+
patches. The subject match is also error prone - a computer has a
diffferent opinion about "match" than the human brain, and a seemingly
innocent subject change may result in a complete mismatch. Also, yes,
there may be multiple patches with the same or almost the same subject.
The ability to replace or at least augment that part of the search
with a uuid match would be extremely helpful.

> At least rebasing (using git rebase) your submissions against upstream will
> keep the part that still hasn't been applied.
> 

Unfortunately, a straight rebase doesn't work for a number of reasons.
In a nutshell we have too many local patches to deal with, in too many
areas of the kernel. Also, the deviation from upstream is in almost all
cases not what we want or need if a downstream patch differs from its
upstream version. We have to use a more intelligent (guided) approach.

Guenter

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 15:33                                                         ` Greg Kroah-Hartman
  2019-08-27 15:42                                                           ` Thomas Gleixner
@ 2019-08-27 18:55                                                           ` Konstantin Ryabitsev
  2019-08-27 19:53                                                             ` Greg Kroah-Hartman
  1 sibling, 1 reply; 105+ messages in thread
From: Konstantin Ryabitsev @ 2019-08-27 18:55 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Tue, 27 Aug 2019 at 11:33, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> >        Link: https://lkml.kernel.org/$Message-ID
> >
> > then you have your UUID tag. The tip bot sends you a reply based on that
> > tag and I know you got some of them already.
>
> I'm using:
>             Link: https://lore.kernel.org/r/$message-id
>
> should we standardize on the lkml one instead as it's shorter?  The lore
> one handles any message id that is on any mailing list it handles, is
> the lkml one the same?

It's the exact same system and the /r/ is always required. I prefer
lore.kernel.org because it doesn't imply that the message is going to
be on the LKML (i.e. it can be on a list that isn't even hosted on
vger.kernel.org).

So, my recommendation is Link: https://lore.kernel.org/r/$message-id

Regards,
-- 
Konstantin Ryabitsev
Kernel.org Systems Administrator
Montéal, Québec

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 18:55                                                           ` Konstantin Ryabitsev
@ 2019-08-27 19:53                                                             ` Greg Kroah-Hartman
  2019-08-27 21:34                                                               ` Joel Fernandes
  0 siblings, 1 reply; 105+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-27 19:53 UTC (permalink / raw)
  To: Konstantin Ryabitsev
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Tue, Aug 27, 2019 at 02:55:28PM -0400, Konstantin Ryabitsev wrote:
> On Tue, 27 Aug 2019 at 11:33, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > >        Link: https://lkml.kernel.org/$Message-ID
> > >
> > > then you have your UUID tag. The tip bot sends you a reply based on that
> > > tag and I know you got some of them already.
> >
> > I'm using:
> >             Link: https://lore.kernel.org/r/$message-id
> >
> > should we standardize on the lkml one instead as it's shorter?  The lore
> > one handles any message id that is on any mailing list it handles, is
> > the lkml one the same?
> 
> It's the exact same system and the /r/ is always required. I prefer
> lore.kernel.org because it doesn't imply that the message is going to
> be on the LKML (i.e. it can be on a list that isn't even hosted on
> vger.kernel.org).
> 
> So, my recommendation is Link: https://lore.kernel.org/r/$message-id

Great, will stick with that one, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 19:53                                                             ` Greg Kroah-Hartman
@ 2019-08-27 21:34                                                               ` Joel Fernandes
  2019-08-27 21:38                                                                 ` Joel Fernandes
  2019-08-28  9:08                                                                 ` Greg Kroah-Hartman
  0 siblings, 2 replies; 105+ messages in thread
From: Joel Fernandes @ 2019-08-27 21:34 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Barret Rhoden, ksummit, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Torokhov,
	Dmitry Vyukov

On Tue, Aug 27, 2019 at 3:53 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Aug 27, 2019 at 02:55:28PM -0400, Konstantin Ryabitsev wrote:
> > On Tue, 27 Aug 2019 at 11:33, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > >        Link: https://lkml.kernel.org/$Message-ID
> > > >
> > > > then you have your UUID tag. The tip bot sends you a reply based on that
> > > > tag and I know you got some of them already.
> > >
> > > I'm using:
> > >             Link: https://lore.kernel.org/r/$message-id
> > >
> > > should we standardize on the lkml one instead as it's shorter?  The lore
> > > one handles any message id that is on any mailing list it handles, is
> > > the lkml one the same?
> >
> > It's the exact same system and the /r/ is always required. I prefer
> > lore.kernel.org because it doesn't imply that the message is going to
> > be on the LKML (i.e. it can be on a list that isn't even hosted on
> > vger.kernel.org).
> >
> > So, my recommendation is Link: https://lore.kernel.org/r/$message-id
>
> Great, will stick with that one, thanks.

I am thinking of how to make this automagic and useful for me. My plan
is (and ymmv):

When I write a patch, have a git hook generate  "Message-Id" in my
patch changelog itself when it is written using Greg/Andrew's
make_message_id. This Message-Id is not the final message-id and is
just for reference purposes for later processing. Then when sending
it, after git format-patch I will do a few things:
  (a) Consult the archive to check the highest value of N for which
Message-Id-<N> does not exist
  (b) Add Message-Id: Message-Id-<N> to the patch header so git
send-email uses this as the Message-Id-<N>
  (c) Add this Message-Id-<N> as a Link: to the changelog;  Possibly
removing Message-Id<N-1> link.
  (d) Remove the original "Message-Id" without the -<N> from the
changelog since it has no purpose.
  (e) Send the patch

This will automatically link all the previous revisions of a patch
vN..vN-1...v1...0.  And also does not need any manual labor - which is
one of the main selling points AIUI of Google's git hooks for using
"Change-Id:".  Also works for Doug's use case and for people wanting
to have a Link: tag.

Such a git hook can then be provided to the kernel community to better
automate their flow of Link: generation. Although the steps (a) to (e)
may require additional tooling and changing of the local git tree at
the time a patch is submitted - which is Ok for my flow but not sure
if it would work for everyone.

Thoughts?

thanks,

- Joel

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 21:34                                                               ` Joel Fernandes
@ 2019-08-27 21:38                                                                 ` Joel Fernandes
  2019-08-28  9:08                                                                 ` Greg Kroah-Hartman
  1 sibling, 0 replies; 105+ messages in thread
From: Joel Fernandes @ 2019-08-27 21:38 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Barret Rhoden, ksummit, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Torokhov,
	Dmitry Vyukov

On Tue, Aug 27, 2019 at 5:34 PM Joel Fernandes <joelaf@google.com> wrote:
>
> On Tue, Aug 27, 2019 at 3:53 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, Aug 27, 2019 at 02:55:28PM -0400, Konstantin Ryabitsev wrote:
> > > On Tue, 27 Aug 2019 at 11:33, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > > >        Link: https://lkml.kernel.org/$Message-ID
> > > > >
> > > > > then you have your UUID tag. The tip bot sends you a reply based on that
> > > > > tag and I know you got some of them already.
> > > >
> > > > I'm using:
> > > >             Link: https://lore.kernel.org/r/$message-id
> > > >
> > > > should we standardize on the lkml one instead as it's shorter?  The lore
> > > > one handles any message id that is on any mailing list it handles, is
> > > > the lkml one the same?
> > >
> > > It's the exact same system and the /r/ is always required. I prefer
> > > lore.kernel.org because it doesn't imply that the message is going to
> > > be on the LKML (i.e. it can be on a list that isn't even hosted on
> > > vger.kernel.org).
> > >
> > > So, my recommendation is Link: https://lore.kernel.org/r/$message-id
> >
> > Great, will stick with that one, thanks.
>
> I am thinking of how to make this automagic and useful for me. My plan
> is (and ymmv):
>
> When I write a patch, have a git hook generate  "Message-Id" in my
> patch changelog itself when it is written using Greg/Andrew's
> make_message_id. This Message-Id is not the final message-id and is
> just for reference purposes for later processing. Then when sending
> it, after git format-patch I will do a few things:
>   (a) Consult the archive to check the highest value of N for which
> Message-Id-<N> does not exist
>   (b) Add Message-Id: Message-Id-<N> to the patch header so git
> send-email uses this as the Message-Id-<N>
>   (c) Add this Message-Id-<N> as a Link: to the changelog;  Possibly
> removing Message-Id<N-1> link.
>   (d) Remove the original "Message-Id" without the -<N> from the
> changelog since it has no purpose.
>   (e) Send the patch
>
> This will automatically link all the previous revisions of a patch
> vN..vN-1...v1...0.  And also does not need any manual labor - which is
> one of the main selling points AIUI of Google's git hooks for using
> "Change-Id:".  Also works for Doug's use case and for people wanting
> to have a Link: tag.
>
> Such a git hook can then be provided to the kernel community to better
> automate their flow of Link: generation. Although the steps (a) to (e)
> may require additional tooling and changing of the local git tree at
> the time a patch is submitted - which is Ok for my flow but not sure
> if it would work for everyone.

Hmm, on second thought, no change to local git tree is needed really,
for this scheme to work.

- Joel

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 22:05                                       ` Thomas Gleixner
@ 2019-08-28  8:50                                         ` Thomas Gleixner
  0 siblings, 0 replies; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-28  8:50 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Tue, 27 Aug 2019, Thomas Gleixner wrote:
> As I did not get a repo set up on git.kernel.org for this yet, find
> attached a git bundle which allows you to clone my repo for now. That works
> like a regular clone

I assumed that this should go under pub/scm/utils which requires
permission, but Konstantin told me just to stick it into ..../tglx/. So here it is:

 git://git.kernel.org/pub/scm/linux/kernel/git/tglx/quilttools

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 15:25                                                       ` Paul E. McKenney
@ 2019-08-28  8:57                                                         ` Dan Carpenter
  0 siblings, 0 replies; 105+ messages in thread
From: Dan Carpenter @ 2019-08-28  8:57 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Tue, Aug 27, 2019 at 08:25:05AM -0700, Paul E. McKenney wrote:
> Someone then reviews the patch and reports a bug.  I update the
> commit with a fix.  Now what I do is this:
> 
> [ paulmck: Update based on blablabla feedback from So And So. ]

It sort of bothers me that there isn't a proper tag for these so they're
are not searchable.  Last week I fixed a bug and a reviewer noticed that
there was a similar issue earlier in the function so I fixed that as
well and sent a v2 but he only gets Reviewed-by credit.  Reviewed-by is
the lamest sort of credit.

It should be that reviewers get credit for finding bugs in patches (no
credit for complaining about checkpatch issues, that is its own reward).

regards,
dan carpenter

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 21:34                                                               ` Joel Fernandes
  2019-08-27 21:38                                                                 ` Joel Fernandes
@ 2019-08-28  9:08                                                                 ` Greg Kroah-Hartman
  2019-08-28  9:25                                                                   ` Jani Nikula
                                                                                     ` (4 more replies)
  1 sibling, 5 replies; 105+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-28  9:08 UTC (permalink / raw)
  To: Joel Fernandes
  Cc: Barret Rhoden, ksummit, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Torokhov,
	Dmitry Vyukov

On Tue, Aug 27, 2019 at 05:34:47PM -0400, Joel Fernandes wrote:
> On Tue, Aug 27, 2019 at 3:53 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, Aug 27, 2019 at 02:55:28PM -0400, Konstantin Ryabitsev wrote:
> > > On Tue, 27 Aug 2019 at 11:33, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > > >        Link: https://lkml.kernel.org/$Message-ID
> > > > >
> > > > > then you have your UUID tag. The tip bot sends you a reply based on that
> > > > > tag and I know you got some of them already.
> > > >
> > > > I'm using:
> > > >             Link: https://lore.kernel.org/r/$message-id
> > > >
> > > > should we standardize on the lkml one instead as it's shorter?  The lore
> > > > one handles any message id that is on any mailing list it handles, is
> > > > the lkml one the same?
> > >
> > > It's the exact same system and the /r/ is always required. I prefer
> > > lore.kernel.org because it doesn't imply that the message is going to
> > > be on the LKML (i.e. it can be on a list that isn't even hosted on
> > > vger.kernel.org).
> > >
> > > So, my recommendation is Link: https://lore.kernel.org/r/$message-id
> >
> > Great, will stick with that one, thanks.
> 
> I am thinking of how to make this automagic and useful for me. My plan
> is (and ymmv):
> 
> When I write a patch, have a git hook generate  "Message-Id" in my
> patch changelog itself when it is written using Greg/Andrew's
> make_message_id. This Message-Id is not the final message-id and is
> just for reference purposes for later processing. Then when sending
> it, after git format-patch I will do a few things:
>   (a) Consult the archive to check the highest value of N for which
> Message-Id-<N> does not exist
>   (b) Add Message-Id: Message-Id-<N> to the patch header so git
> send-email uses this as the Message-Id-<N>
>   (c) Add this Message-Id-<N> as a Link: to the changelog;  Possibly
> removing Message-Id<N-1> link.
>   (d) Remove the original "Message-Id" without the -<N> from the
> changelog since it has no purpose.
>   (e) Send the patch

Wow, what an overly complex thing for something that should be trivial
to do...

How about this, when sending a v2, you have it be in response to the v1
patch?  Same for v3, have it be in response for the v2 one.  And so on.

Then, when the "final" patch is added, the message id of that will be
committed to the tree with the git hook that has been posted here, and
then, if someone _REALLY_ wants to go look up past history of versions,
they can see it all linked together in a nice pretty tree on
lore.kernel.org or elsewhere.

And really, this whole discussion has been for the VERY RARE case of
when someone wants to do some code spelunking and try to figure out
older versions of a patch history before it was committed and they don't
feel like searching for the author's name instead.  The HUGE majority of
kernel developers never actually care about this as they don't have to
do it.

ugh,

greg k-h

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28  9:08                                                                 ` Greg Kroah-Hartman
@ 2019-08-28  9:25                                                                   ` Jani Nikula
  2019-08-28 10:04                                                                   ` Martin K. Petersen
                                                                                     ` (3 subsequent siblings)
  4 siblings, 0 replies; 105+ messages in thread
From: Jani Nikula @ 2019-08-28  9:25 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Joel Fernandes
  Cc: Barret Rhoden, ksummit, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Torokhov,
	Dmitry Vyukov

On Wed, 28 Aug 2019, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> Then, when the "final" patch is added, the message id of that will be
> committed to the tree with the git hook that has been posted here, and
> then, if someone _REALLY_ wants to go look up past history of versions,
> they can see it all linked together in a nice pretty tree on
> lore.kernel.org or elsewhere.
>
> And really, this whole discussion has been for the VERY RARE case of
> when someone wants to do some code spelunking and try to figure out
> older versions of a patch history before it was committed and they don't
> feel like searching for the author's name instead.  The HUGE majority of
> kernel developers never actually care about this as they don't have to
> do it.

For me the Link: tag is also a bit of audit trail, if you will. You can
easily check that the patch was actually posted for review on a public
list, and nobody sneaked it in without review. (And in drm/i915 we point
the Link: tag at our patchwork which also contains the CI results we
require.)

When I've found myself looking at the actual discussion or earlier patch
versions, it's almost always because the commit message falls short. A
link to the discussion should never be a replacement for a proper commit
message.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28  9:08                                                                 ` Greg Kroah-Hartman
  2019-08-28  9:25                                                                   ` Jani Nikula
@ 2019-08-28 10:04                                                                   ` Martin K. Petersen
  2019-08-28 10:53                                                                     ` Thomas Gleixner
  2019-08-28 10:42                                                                   ` Mark Brown
                                                                                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 105+ messages in thread
From: Martin K. Petersen @ 2019-08-28 10:04 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov


Greg,

> How about this, when sending a v2, you have it be in response to the
> v1 patch?  Same for v3, have it be in response for the v2 one.  And so
> on.

I spend a ton of time tracking older versions of series (subjects often
change).

However, requiring proper follow-up headers is yet another thing for me
to manually police. Maybe we could add a line of defense and make
patchwork complain if somebody posts a -vN without a suitable
--in-reply-to?

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28  9:08                                                                 ` Greg Kroah-Hartman
  2019-08-28  9:25                                                                   ` Jani Nikula
  2019-08-28 10:04                                                                   ` Martin K. Petersen
@ 2019-08-28 10:42                                                                   ` Mark Brown
  2019-08-28 11:41                                                                     ` Greg Kroah-Hartman
  2019-08-28 12:22                                                                   ` Christian Brauner
  2019-08-28 12:38                                                                   ` Joel Fernandes
  4 siblings, 1 reply; 105+ messages in thread
From: Mark Brown @ 2019-08-28 10:42 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

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

On Wed, Aug 28, 2019 at 11:08:37AM +0200, Greg Kroah-Hartman wrote:

> How about this, when sending a v2, you have it be in response to the v1
> patch?  Same for v3, have it be in response for the v2 one.  And so on.

That seems like it might confuse mail readers and have them do
interesting things with threading so they don't group the entire new
version of the series together but instead split it through the earlier
versions.

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28 10:04                                                                   ` Martin K. Petersen
@ 2019-08-28 10:53                                                                     ` Thomas Gleixner
  2019-08-28 12:46                                                                       ` Martin K. Petersen
  0 siblings, 1 reply; 105+ messages in thread
From: Thomas Gleixner @ 2019-08-28 10:53 UTC (permalink / raw)
  To: Martin K. Petersen
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Wed, 28 Aug 2019, Martin K. Petersen wrote:
> > How about this, when sending a v2, you have it be in response to the
> > v1 patch?  Same for v3, have it be in response for the v2 one.  And so
> > on.
> 
> I spend a ton of time tracking older versions of series (subjects often
> change).
> 
> However, requiring proper follow-up headers is yet another thing for me
> to manually police. Maybe we could add a line of defense and make
> patchwork complain if somebody posts a -vN without a suitable
> --in-reply-to?

That's horrible in various mail clients. Post the new series stand alone
and add

    Link://lore.kernel.org/r/$MESSAGE_ID_OF_V$N-1

to the cover letter and you have a trail.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28 10:42                                                                   ` Mark Brown
@ 2019-08-28 11:41                                                                     ` Greg Kroah-Hartman
  0 siblings, 0 replies; 105+ messages in thread
From: Greg Kroah-Hartman @ 2019-08-28 11:41 UTC (permalink / raw)
  To: Mark Brown
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Wed, Aug 28, 2019 at 11:42:19AM +0100, Mark Brown wrote:
> On Wed, Aug 28, 2019 at 11:08:37AM +0200, Greg Kroah-Hartman wrote:
> 
> > How about this, when sending a v2, you have it be in response to the v1
> > patch?  Same for v3, have it be in response for the v2 one.  And so on.
> 
> That seems like it might confuse mail readers and have them do
> interesting things with threading so they don't group the entire new
> version of the series together but instead split it through the earlier
> versions.

Works fine with mutt :)

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28  9:08                                                                 ` Greg Kroah-Hartman
                                                                                     ` (2 preceding siblings ...)
  2019-08-28 10:42                                                                   ` Mark Brown
@ 2019-08-28 12:22                                                                   ` Christian Brauner
  2019-08-28 12:38                                                                   ` Joel Fernandes
  4 siblings, 0 replies; 105+ messages in thread
From: Christian Brauner @ 2019-08-28 12:22 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Wed, Aug 28, 2019 at 11:08:37AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 27, 2019 at 05:34:47PM -0400, Joel Fernandes wrote:
> > On Tue, Aug 27, 2019 at 3:53 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > On Tue, Aug 27, 2019 at 02:55:28PM -0400, Konstantin Ryabitsev wrote:
> > > > On Tue, 27 Aug 2019 at 11:33, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > > >        Link: https://lkml.kernel.org/$Message-ID
> > > > > >
> > > > > > then you have your UUID tag. The tip bot sends you a reply based on that
> > > > > > tag and I know you got some of them already.
> > > > >
> > > > > I'm using:
> > > > >             Link: https://lore.kernel.org/r/$message-id
> > > > >
> > > > > should we standardize on the lkml one instead as it's shorter?  The lore
> > > > > one handles any message id that is on any mailing list it handles, is
> > > > > the lkml one the same?
> > > >
> > > > It's the exact same system and the /r/ is always required. I prefer
> > > > lore.kernel.org because it doesn't imply that the message is going to
> > > > be on the LKML (i.e. it can be on a list that isn't even hosted on
> > > > vger.kernel.org).
> > > >
> > > > So, my recommendation is Link: https://lore.kernel.org/r/$message-id
> > >
> > > Great, will stick with that one, thanks.
> > 
> > I am thinking of how to make this automagic and useful for me. My plan
> > is (and ymmv):
> > 
> > When I write a patch, have a git hook generate  "Message-Id" in my
> > patch changelog itself when it is written using Greg/Andrew's
> > make_message_id. This Message-Id is not the final message-id and is
> > just for reference purposes for later processing. Then when sending
> > it, after git format-patch I will do a few things:
> >   (a) Consult the archive to check the highest value of N for which
> > Message-Id-<N> does not exist
> >   (b) Add Message-Id: Message-Id-<N> to the patch header so git
> > send-email uses this as the Message-Id-<N>
> >   (c) Add this Message-Id-<N> as a Link: to the changelog;  Possibly
> > removing Message-Id<N-1> link.
> >   (d) Remove the original "Message-Id" without the -<N> from the
> > changelog since it has no purpose.
> >   (e) Send the patch
> 
> Wow, what an overly complex thing for something that should be trivial
> to do...

Agreed.
We also have simpler ways of doing this which were brought up here multiple
times and which can likely be automated and or gain more adoption if properly documented.
Here's an example of how a bunch of people (including me) are already
doing this. All commits currently in my tree that had multiple versions
do as the last line have a lore-Link tag. (This is based on the script
by Kees that came out of a prior discussion.). Here is an example for
the waitid patch for 5.4-rc1
( https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/commit/?h=pidfd&id=590ef0128b4277eaa9cb74d7ba878d48b261950c ):

	waitid: Add support for waiting for the current process group
	It was recently discovered that the linux version of waitid is not a
	superset of the other wait functions because it does not include support
	
	[...]
	
	Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
	Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
	[...]
	Link: https://lore.kernel.org/r/20190814154400.6371-2-christian.brauner@ubuntu.com

If you click on that link it takes you to the patch sent to the mailing
list that was actually applied. The actual version might differ because
of merge-conflict resolution. In this example it was v3. The cover
letter for v3
( https://lore.kernel.org/lkml/20190814154400.6371-1-christian.brauner@ubuntu.com/ )
contains lore-Links to all previous versions of the patchset:

	Hey everyone,
	
	[...]
	
	Thanks!
	Christian
	
	/* v0 */
	Link: https://www.sourceware.org/ml/libc-alpha/2019-07/msg00587.html
	
	/* v1 */
	Link: https://lore.kernel.org/lkml/20190814113822.9505-1-christian.brauner@ubuntu.com/
	
	/* v2 */
	Link: https://lore.kernel.org/lkml/20190814130732.23572-1-christian.brauner@ubuntu.com

That's a pretty simple trail to all versions of the patchset. If no
cover letter is wanted or needed placing it after --- works just as
well.

> 
> How about this, when sending a v2, you have it be in response to the v1
> patch?  Same for v3, have it be in response for the v2 one.  And so on.

As long as you have the link to the prior version in the patchset you
can even skip this part.

Christian

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 23:43                                             ` Thomas Gleixner
@ 2019-08-28 12:34                                               ` Christian Brauner
  0 siblings, 0 replies; 105+ messages in thread
From: Christian Brauner @ 2019-08-28 12:34 UTC (permalink / raw)
  To: Thomas Gleixner, dianders
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Tue, Aug 27, 2019 at 01:43:23AM +0200, Thomas Gleixner wrote:
> On Mon, 26 Aug 2019, Theodore Y. Ts'o wrote:
> > On Mon, Aug 26, 2019 at 03:06:43PM -0700, Doug Anderson wrote:
> > > 2. If, as I expect, Change-Id as part of the patch stays NAKed then I
> > > will modify the tools I use to post upstream (currently patman) to
> > > encode the Change-Id.  My naive proposal would be:
> > > 
> > > Message-Id: ChangeId-YYYY-MMDD-HHMMSS-PatchNum
> > > 
> > > If I try this and it works for me then I will post out and suggest
> > > that any other like-minded people encode Change-Id into Message-Id in
> > > a similar way.
> > 
> > ... and I would expect patches with this would get NACK'ed because
> > they would be just as useless as Change-Id's are perceived to be
> > today.  People who are gaming the rules will tend not to looked upon
> > favorably; the same will apply to their patches.
> > 
> > BTW, the Message-Id you've listed above is not legal, per RFC-5322.  A
> > msg-id has to look like a e-mail address (left-hand-side@example.com).
> > So something like this is legal as a message id:
> > 
> > I3268f9036512c4378cde1da37e0612b43ed4d384@linux-review.googlesource.com
> > 
> > ... and indeed, that's more useful, because it tells us how to
> > interpret I3268f9036512c4378cde1da37e0612b43ed4d384 --- it's a
> > Change-Id assigned by the linux-review.googlesource.com Gerrit server.
> > 
> > In contrast a bare "I3268f9036512c4378cde1da37e0612b43ed4d384" is
> > going to be presumed to be useless.  And in fact, a Google search for
> > this ID returns *nothing*.  Yet visiting the link
> > https://linux-review.googlesource.com/c/1158 actually returns
> > something useful.   That's why the latter is superior to the former.
> 
> That's fine, but the point is that nobody will prevent you from frobbing
> your message-id's in a way which encodes other information into it as long
> as the message-id is RFC compliant. We simply don't care because the result
> is just a message-id as any other in the mail header of your patch
> submission,
> 
> I agree that a full gerrit link is more useful, but what Doug described is
> not connected to a gerrit server at all. He just (ab)uses the tooling which
> allows him to create a unique ID to track versions of his patches.
> 
> Actually not the worst idea. If the result is not part of the changelog and
> just part of the email then generating the id with
> 
>      id = make_msgid(ChangeId)
> 
> will still generate something useful for everyone because we can add:
> 
>      Link: https://lore.kernel.org/lkml/$id
> 
> and Doug can grep the archives for $id.
> 
> I truly don't care whether the Message-ID header contains extra information
> as long as it is properly formatted.

This whole thread is rather complex at this point. I have been sick for
a few days now and couldn't follow it too closely because of that. At
this point it kinda feels like there's some agreement on using Link:
instead of Change-Id: but I'm not sure what best practives are for
generating this Link: including the message id and wher it needs to be
placed (commit message, after ---, only in email header?). So the most
important task is to document what exactly is considered good practice
somewhere (probably in the kernel docs):

@Doug, are you planning on sending a docs patch for this or sm?

Christian

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28  9:08                                                                 ` Greg Kroah-Hartman
                                                                                     ` (3 preceding siblings ...)
  2019-08-28 12:22                                                                   ` Christian Brauner
@ 2019-08-28 12:38                                                                   ` Joel Fernandes
  2019-08-28 13:58                                                                     ` Theodore Y. Ts'o
  4 siblings, 1 reply; 105+ messages in thread
From: Joel Fernandes @ 2019-08-28 12:38 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Barret Rhoden, ksummit, Jonathan Nieder, Tomasz Figa,
	Han-Wen Nienhuys, Theodore Tso, David Rientjes, Dmitry Torokhov,
	Dmitry Vyukov

On Wed, Aug 28, 2019 at 5:08 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Aug 27, 2019 at 05:34:47PM -0400, Joel Fernandes wrote:
> > On Tue, Aug 27, 2019 at 3:53 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > On Tue, Aug 27, 2019 at 02:55:28PM -0400, Konstantin Ryabitsev wrote:
> > > > On Tue, 27 Aug 2019 at 11:33, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > > >        Link: https://lkml.kernel.org/$Message-ID
> > > > > >
> > > > > > then you have your UUID tag. The tip bot sends you a reply based on that
> > > > > > tag and I know you got some of them already.
> > > > >
> > > > > I'm using:
> > > > >             Link: https://lore.kernel.org/r/$message-id
> > > > >
> > > > > should we standardize on the lkml one instead as it's shorter?  The lore
> > > > > one handles any message id that is on any mailing list it handles, is
> > > > > the lkml one the same?
> > > >
> > > > It's the exact same system and the /r/ is always required. I prefer
> > > > lore.kernel.org because it doesn't imply that the message is going to
> > > > be on the LKML (i.e. it can be on a list that isn't even hosted on
> > > > vger.kernel.org).
> > > >
> > > > So, my recommendation is Link: https://lore.kernel.org/r/$message-id
> > >
> > > Great, will stick with that one, thanks.
> >
> > I am thinking of how to make this automagic and useful for me. My plan
> > is (and ymmv):
> >
> > When I write a patch, have a git hook generate  "Message-Id" in my
> > patch changelog itself when it is written using Greg/Andrew's
> > make_message_id. This Message-Id is not the final message-id and is
> > just for reference purposes for later processing. Then when sending
> > it, after git format-patch I will do a few things:
> >   (a) Consult the archive to check the highest value of N for which
> > Message-Id-<N> does not exist
> >   (b) Add Message-Id: Message-Id-<N> to the patch header so git
> > send-email uses this as the Message-Id-<N>
> >   (c) Add this Message-Id-<N> as a Link: to the changelog;  Possibly
> > removing Message-Id<N-1> link.
> >   (d) Remove the original "Message-Id" without the -<N> from the
> > changelog since it has no purpose.
> >   (e) Send the patch
>
> Wow, what an overly complex thing for something that should be trivial
> to do...

The idea is to make it trivial. All of the steps above are automatic
and scripted, that's the whole point of what I was saying - to make it
automatic. If it is not automated, then it is unlikely to be adopted
widely or unlikely to stick. The final user will experience it as
trivial.

> How about this, when sending a v2, you have it be in response to the v1
> patch?  Same for v3, have it be in response for the v2 one.  And so on.

If I remember correctly, the in-reply-to method has drawbacks and is
not always desired especially when dealing with a whole series. In
such a case of a whole series, the individual patches are replies to
the cover-letter (as --thread of git format-patch does); they should
not be replies to old versions of that patch; otherwise the threading
looks really weird and confusing.

Plus your response suggestion still does not make it automatic. How
does sending of a v2 know that it is reply to a v1? Some metadata has
to be stored in your git tree for that. That's the whole point of the
steps I listed above.

> Then, when the "final" patch is added, the message id of that will be
> committed to the tree with the git hook that has been posted here, and
> then, if someone _REALLY_ wants to go look up past history of versions,
> they can see it all linked together in a nice pretty tree on
> lore.kernel.org or elsewhere.
>
> And really, this whole discussion has been for the VERY RARE case of
> when someone wants to do some code spelunking and try to figure out
> older versions of a patch history before it was committed and they don't
> feel like searching for the author's name instead.  The HUGE majority of
> kernel developers never actually care about this as they don't have to
> do it.

I think it is a frequent use case that folks want to look up old
revisions of a patch and follow the review/discussions of previous
revisions to know the history of how a patch got to where it is.  I
think it can be really useful.

thanks,

 - Joel

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28 10:53                                                                     ` Thomas Gleixner
@ 2019-08-28 12:46                                                                       ` Martin K. Petersen
  0 siblings, 0 replies; 105+ messages in thread
From: Martin K. Petersen @ 2019-08-28 12:46 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov


Thomas,

>> However, requiring proper follow-up headers is yet another thing for me
>> to manually police. Maybe we could add a line of defense and make
>> patchwork complain if somebody posts a -vN without a suitable
>> --in-reply-to?
>
> That's horrible in various mail clients. Post the new series stand alone
> and add
>
>     Link://lore.kernel.org/r/$MESSAGE_ID_OF_V$N-1
>
> to the cover letter and you have a trail.

I'm not sure why it would get messed up if the patches are clearly
tagged as vN?

As far as I'm concerned, the more we automate, the better. Both in terms
of producing the links, but also in terms of verifying that they are
present and correct when patches are applied.

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28 12:38                                                                   ` Joel Fernandes
@ 2019-08-28 13:58                                                                     ` Theodore Y. Ts'o
  2019-08-28 20:39                                                                       ` Doug Anderson
  0 siblings, 1 reply; 105+ messages in thread
From: Theodore Y. Ts'o @ 2019-08-28 13:58 UTC (permalink / raw)
  To: Joel Fernandes
  Cc: Barret Rhoden, ksummit, Greg Kroah-Hartman, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

On Wed, Aug 28, 2019 at 08:38:33AM -0400, Joel Fernandes via Ksummit-discuss wrote:
> The idea is to make it trivial. All of the steps above are automatic
> and scripted, that's the whole point of what I was saying - to make it
> automatic. If it is not automated, then it is unlikely to be adopted
> widely or unlikely to stick. The final user will experience it as
> trivial.

I'm going to gently suggest that we've reached the point where instead
of people trying to argue for their suggested solution is to actually
*implement* a prototype.  It'll be a lot easier for people to judge a
particular solution if it exists, than to debate about vaporware.

Code implementing automation can always be adjusted, and questions
over whether the Link: trailer should be using lkml.kernel.org or
lore.kernel.org is really paint shedding.

Also remember that, different people can start using different
automations, and even different schemes, in parallel, and we can
actually try them out and see which is:

* most convenient for the patch submmiter
* most convenient for the maintainer
* most convenient for people who are doing code archeology

etc.  Then we can decide on what we want to use.  Trying to pick
something before people who actually have to use it day to day have
had a chance to try it in real life is how CIO's end up picking Lotus
Notes.

Even people who are arguing for using Change-Id will have better luck
if there is a commonly available solution in active use which makes
Change-Id's actually *useful* as a search token, as opposed to today,
where it is viewed (in practical terms, given today's usage, mostly
correctly) as a proxy for Gerrit instances hidden behind corporate
firewalls.

						- Ted

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28 13:58                                                                     ` Theodore Y. Ts'o
@ 2019-08-28 20:39                                                                       ` Doug Anderson
  2019-08-28 20:46                                                                         ` Johannes Berg
  2019-08-28 22:15                                                                         ` Rob Herring
  0 siblings, 2 replies; 105+ messages in thread
From: Doug Anderson @ 2019-08-28 20:39 UTC (permalink / raw)
  To: Theodore Y. Ts'o, Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi,

On Wed, Aug 28, 2019 at 6:58 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Wed, Aug 28, 2019 at 08:38:33AM -0400, Joel Fernandes via Ksummit-discuss wrote:
> > The idea is to make it trivial. All of the steps above are automatic
> > and scripted, that's the whole point of what I was saying - to make it
> > automatic. If it is not automated, then it is unlikely to be adopted
> > widely or unlikely to stick. The final user will experience it as
> > trivial.
>
> I'm going to gently suggest that we've reached the point where instead
> of people trying to argue for their suggested solution is to actually
> *implement* a prototype.  It'll be a lot easier for people to judge a
> particular solution if it exists, than to debate about vaporware.

For anyone interested, I've prototyped up my proposed solution.  I
personally use patman (a tool hosted in U-Boot) for managing my
upstream posting so I have posted a patch to patman that encodes the
Change-Id in Message-Id.  We will see what folks there think of it.
There are at least a handful of other people who use patman for Linux
but lots in U-Boot so maybe it'll be a good way to get a feel for
this.

Feel free to look at:

https://patchwork.ozlabs.org/patch/1154833/

The actual Message-Id generated there was:

20190828132723.0.RFC.Ie6289f437ae533d7fcaddfcee9202f0e92c6b2b9@changeid

Thomas Gleixner: I tried using the python library to generate a
Message-Id but it produced something that was way too long and I felt
that would be a showstopper when a maintainer in Linux tried to
provide a "Link:" to one of my patches.  I have generated my own
format based on what Rob Herring seems to do (an example Message-Id I
see from him is "20190827223716.GA31605@bogus").

Theodore Ts'o: Hopefully what I have done counts as a prototype for you.

Christian Brauner: I am not planning on posting any Documentation
changes.  I feel like it's sane to get a feel for this right now and
see how people like it.


I didn't CC everyone on this list on my patch, but it should be easy
for anyone interested to subscribe to the U-Boot mailing list.


-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28 20:39                                                                       ` Doug Anderson
@ 2019-08-28 20:46                                                                         ` Johannes Berg
  2019-08-28 21:00                                                                           ` Doug Anderson
  2019-08-28 22:15                                                                         ` Rob Herring
  1 sibling, 1 reply; 105+ messages in thread
From: Johannes Berg @ 2019-08-28 20:46 UTC (permalink / raw)
  To: Doug Anderson, Theodore Y. Ts'o, Thomas Gleixner
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi Doug,


> The actual Message-Id generated there was:
> 
> 20190828132723.0.RFC.Ie6289f437ae533d7fcaddfcee9202f0e92c6b2b9@changeid

When you post a patch with that type of message ID, why don't you
already include a suitable archive Link: inside the patch posting?

Then you don't have to rely on the maintainer to add the Link: tag when
they apply the patch. Many (kernel) maintainers do now, and pre-adding
the Link: tag means we maintainers should change our scripts to not
duplicate the Link: tag, but if you have a predictable Message-Id and
predictable archive then you ought to be able to already include link?

johannes

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28 20:46                                                                         ` Johannes Berg
@ 2019-08-28 21:00                                                                           ` Doug Anderson
  0 siblings, 0 replies; 105+ messages in thread
From: Doug Anderson @ 2019-08-28 21:00 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi,

On Wed, Aug 28, 2019 at 1:47 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Hi Doug,
>
>
> > The actual Message-Id generated there was:
> >
> > 20190828132723.0.RFC.Ie6289f437ae533d7fcaddfcee9202f0e92c6b2b9@changeid
>
> When you post a patch with that type of message ID, why don't you
> already include a suitable archive Link: inside the patch posting?
>
> Then you don't have to rely on the maintainer to add the Link: tag when
> they apply the patch. Many (kernel) maintainers do now, and pre-adding
> the Link: tag means we maintainers should change our scripts to not
> duplicate the Link: tag, but if you have a predictable Message-Id and
> predictable archive then you ought to be able to already include link?

That might work, but a few issues:

1. I'd have to guess that the Link would be valid.  Until the patch is
posted the Link is certainly not valid, so I'm basically adding to the
patch something that says "I _think_ you'd be able to find this patch
with this link".  Seems a little sketchy.

2. The script would (presumably) want to look at where the patch was
mailed to and either generate different links or not generate a link
in some cases.  Last I checked (maybe fixed now?) some mailing lists
weren't archived on lore.kernel.org and not everyone CCs LKML.  If
nothing else the people using this script for posting patches to
U-Boot wouldn't want a Link to lore.kernel.org

3. The link is of limited usefulness until it lands in the kernel
tree, isn't it?  If you found the patch on the mailing list before it
lands then presumably you don't need a link to the patch itself.  A
link to previous versions could be useful, but I'm not trying to solve
that (I'm assuming that tooling would eventually be developed that
could use the Change-Id encoded in the Message-Id to help with this).

4. It feels like getting maintainers to add a "Link:" is a tractable
(even if difficult) problem.  There are a finite number of maintainers
that can be told to do this instead of an infinite number of
submitters.  Presumably maintainers already need to learn to add
"Link:" anyway since (even if I am surprised and lots of people adopt
my proposal) you'll never get 100% of submitters adding a "Link:" like
this.


-Doug

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-28 20:39                                                                       ` Doug Anderson
  2019-08-28 20:46                                                                         ` Johannes Berg
@ 2019-08-28 22:15                                                                         ` Rob Herring
  1 sibling, 0 replies; 105+ messages in thread
From: Rob Herring @ 2019-08-28 22:15 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Wed, Aug 28, 2019 at 3:39 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Aug 28, 2019 at 6:58 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> >
> > On Wed, Aug 28, 2019 at 08:38:33AM -0400, Joel Fernandes via Ksummit-discuss wrote:
> > > The idea is to make it trivial. All of the steps above are automatic
> > > and scripted, that's the whole point of what I was saying - to make it
> > > automatic. If it is not automated, then it is unlikely to be adopted
> > > widely or unlikely to stick. The final user will experience it as
> > > trivial.
> >
> > I'm going to gently suggest that we've reached the point where instead
> > of people trying to argue for their suggested solution is to actually
> > *implement* a prototype.  It'll be a lot easier for people to judge a
> > particular solution if it exists, than to debate about vaporware.
>
> For anyone interested, I've prototyped up my proposed solution.  I
> personally use patman (a tool hosted in U-Boot) for managing my
> upstream posting so I have posted a patch to patman that encodes the
> Change-Id in Message-Id.  We will see what folks there think of it.
> There are at least a handful of other people who use patman for Linux
> but lots in U-Boot so maybe it'll be a good way to get a feel for
> this.
>
> Feel free to look at:
>
> https://patchwork.ozlabs.org/patch/1154833/


>
> The actual Message-Id generated there was:
>
> 20190828132723.0.RFC.Ie6289f437ae533d7fcaddfcee9202f0e92c6b2b9@changeid
>
> Thomas Gleixner: I tried using the python library to generate a
> Message-Id but it produced something that was way too long and I felt
> that would be a showstopper when a maintainer in Linux tried to
> provide a "Link:" to one of my patches.  I have generated my own
> format based on what Rob Herring seems to do (an example Message-Id I
> see from him is "20190827223716.GA31605@bogus").

FWIW, that's just mutt configuration to not expose your hostname:

set hidden_host = yes
set hostname = bogus

Rob

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-22 23:39 [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits Doug Anderson
  2019-08-23  0:03 ` Brendan Higgins
  2019-08-23  0:17 ` Linus Torvalds
@ 2019-09-05  8:12 ` Eric Wong
  2 siblings, 0 replies; 105+ messages in thread
From: Eric Wong @ 2019-09-05  8:12 UTC (permalink / raw)
  To: Doug Anderson; +Cc: ksummit-discuss

Doug Anderson <dianders@chromium.org> wrote:
> Hi,
> 
> As everyone is probably aware, when you use the gerrit code review
> system all of your commits get an extra line in them that looks
> something like:
> 
> Change-Id: I6a007dfe91ee1077a437963cf26d91370fdd9556
> 
> The Linux kernel has always viewed these Change-Id tags as obnoxious
> and useless spam.  Anyone who accidentally leaves a Change-Id in their
> patch when posting to the mailing list is told to please re-post their
> patch without the Change-Id.  In this email, I will attempt to argue
> that the Linux kernel ought to relax this restriction and allow
> (possibly even encourage) Change-Ids.

Hello Doug, sometimes-present public-inbox author here, chiming
in late, replying off Mailman-mangled archives...

> To begin with, let me make sure we're on the same page about what
> Change-Ids are.  As I understand it:
> 
> * A change ID is much alike a UUID.  It is locally generated on a
> developer's computer and is (in theory) unique across the universe.
> 
> * When a developer keeps the same Change-Id across two patches they
> are making the assertion that the two patches are either the same or
> should be treated as two versions of the same logical change.  For
> instance, v1, v2, and v3 of the same patch should have the same
> Change-Id.  Even if v2 and v3 of the patch have different subjects and
> touch different files, if they have the same Change-Id then the
> developer is asserting that v3 should be considered a new version of
> the same logical change as v2.  If it helps to think about it,
> Change-Id is used by gerrit servers to know that a new patch uploaded
> should replace an older version with the same Change-Id.

This sounds like the debates around rename-tracking in VCSes
circa 2005.

Other VCSes at the time had explicit rename tracking; git was
(and still is :) powerful enough to infer renames without extra
input from the user.

Drawing inspiration from git from not having "arch-id:" tags
or other cruft for rename-tracking; MY philosophy is to have
"Really Powerful Search" being able to tie things together
after-the-fact without user intervention.

The "Really Powerful Search" part is something I've been working
on in public-inbox off-and-on for a few years :)

> Specifically, let me list the problems I'd like to solve:
> 
> 1. If I see a commit in Linux, I would like to be able to easily find
> all of the mailing list discussions relevant to that commit.  I know
> there are proposals about including the Message-Id of the final post
> in the commit log and that is certainly better than nothing, but the
> Message-Id will only get you a link to the final version of the patch.
> If the relevant discussion happened on a previous version of that
> patch then you need to find it yourself.  This gets harder if the
> patch changed subject, touched different files, if parts of the series
> landed at different times, and if multiple people were involved in
> posting different versions of the patch.  If the commit in Linux has a
> Change-Id then the old versions are logically linked and easier to
> associated with one another.
> 
> 2. If I do a search through old mailing list archives and I stumble
> upon a patch that didn't land, I can more easily find different
> versions of that patch if I have a Change-Id.  Some of these different
> versions may have relevant discussions that explains why the patch
> didn't land.  Finding these other patches without a Change-Id might be
> hard, again because they may touch different files, have a different
> subject, or have been posted by a different person.

I'm curious if you're taking advantage some of the public-inbox
search features (in lore.kernel.org) which is designed with
patches in mind.

1. "Phrase searching" with double quotes can be combined with the "s:"
   prefix to search most commit titles/subjects (*).

2. The dfa:/dfb: prefixes could be an alternative to "git blame"
   for searching text (and works for pre-git patches)

3. dfpre:/dfpost:/dfblob: can find exact blob SHA-1s

4. date/author can also match the git commit authorship info

5. all or any combination of the above can be combined in a single
   search to improve results

All the Xapian prefixes are documented at $INBOX_URL/_text/help/, e.g:
<https://public-inbox.org/git/_/text/help/>

I'm also planning to support searching for the output of
"git patch-id --stable" in the future.  public-inbox also lacks
pairity with "mairix -t" (being able to grab an entire thread
if on message in the thread matches).

> At the moment using a Change-Id in the way I described would require
> searching through mailing lists for the Change-Id string to find other
> versions of the same patch.  However, I would expect it would only be
> a matter of time before tools like patchwork are able to use Change-Id
> to associate one version of a patch with the next version.  I would
> also expect that allowing Change-Id to exist would allow someone to
> (perhaps) create a gerrit instance that watched the kernel mailing
> list and mirrored mailing list discussions in the GUI.  In other
> words, once such tools exist presumably Change-Id will be much more
> useful: you will eventually be able to paste a Change-Id into a tool
> and get links to all relevant discussion and related posts.

(*) I'm also linking the phrase searching through cgit to link
    commit titles to mail discussions shown below:

    https://80x24.org/mirrors/git.git/commit/?id=b777f3fd619ac2af507ffd3e7c5fe0d6e36e81f2
    (following the "xdiff: clamp function context indices in post-image"
     link brings the public-inbox.org/git discussion)

    That's all done with a Lua script supported via cgit:
    https://80x24.org/public-inbox.git/tree/examples/cgit-commit-filter.lua
    It works OK in most cases, but would need to be combined (as
    noted in 5.) for best results.

    I haven't gotten dfpre/dfpost/dfblob/dfa/dfb links working via
    cgit + Lua, yet.  It's on my personal roadmap, some hacking on
    cgit will be needed to expose that info (and I keep getting
    sidetracked on other stuff)

> The basic summary is that I'd like there to be some way to track a
> logical patch over its lifetime.  I don't believe there is a reliable
> (non-heuristic) way to do this today and I think Change-Id provides a
> nice solution.  While we could come up with a new and different
> solution (because Change-Id was not invented here), it feels like
> adopting Change-Id is convenient and easy and provides a true benefit.
> Change-Id works super well with the decentralized/email workflow for
> patches and can be phased in over time (or it can stay optional
> forever).

This sounds exactly like the "arch-id:" comments GNU arch users
used to pollute their sources with for rename tracking :)

It's ugly and made redundant by something which understands
the content.

Change-Id also won't work for historical patches (including
pre-git stuff).  Even without relying on git blob IDs for search,
matching on exact text/phrases is pretty good for pre-git
patches, already.

And back to rename tracking, one yet-to-be-realized promise from
git's lack of explicit tracking was being able to track code
movements (individual functions or hunks, not just entire files).
Having a good search engine gets us there :)

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-27 10:51                                         ` Mark Brown
@ 2019-09-09  8:14                                           ` Michael Ellerman
  2019-09-09 12:09                                             ` Mark Brown
  0 siblings, 1 reply; 105+ messages in thread
From: Michael Ellerman @ 2019-09-09  8:14 UTC (permalink / raw)
  To: Mark Brown, Greg Kroah-Hartman
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Jonathan Nieder,
	Tomasz Figa, Han-Wen Nienhuys, Theodore Tso, David Rientjes,
	Dmitry Torokhov, Dmitry Vyukov

Mark Brown <broonie@kernel.org> writes:
> On Sun, Aug 25, 2019 at 05:11:43AM +0200, Greg Kroah-Hartman wrote:
>
>> When accepting patches from people, my old scripts used to do this
>> properly and reply to the sent message-id.  Now that I use git, that's
>> lost, except that I now am generating Link: tags in the commit message
>> itself, like:
>> 	Link: https://lore.kernel.org/r/20190822213659.5501-1-hsiangkao@aol.com
>
>> Hm, I guess I do now keep that info, and I can fix my scripts to
>> properly thread things, let me go work on that later today...
>
> What I'm doing for this is that when I apply the patch I save a
> git note with the message ID and various other things then when I
> push the patch out and generate the "applied, thanks" e-mail I
> look for the git note and use that.

I was doing something similar with git notes, but the beauty of a
Link: that includes the message id is it gives you everything you need
to send those "applied" mails without any extra state.

I also have a local message-id <=> patchwork id mapping, and that means
I can also do the patchwork state update based purely off the Link: tag.

There is an open patchwork issue to allow lookup by message id, which
would make that local mapping unnecessary too:

  https://github.com/getpatchwork/patchwork/issues/106

If only the patchwork maintainers weren't all volunteers they could get
that implemented some time ;)

cheers

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-09-09  8:14                                           ` Michael Ellerman
@ 2019-09-09 12:09                                             ` Mark Brown
  0 siblings, 0 replies; 105+ messages in thread
From: Mark Brown @ 2019-09-09 12:09 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

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

On Mon, Sep 09, 2019 at 06:14:19PM +1000, Michael Ellerman wrote:
> Mark Brown <broonie@kernel.org> writes:

> > What I'm doing for this is that when I apply the patch I save a
> > git note with the message ID and various other things then when I
> > push the patch out and generate the "applied, thanks" e-mail I
> > look for the git note and use that.

> I was doing something similar with git notes, but the beauty of a
> Link: that includes the message id is it gives you everything you need
> to send those "applied" mails without any extra state.

Yeah, you can definitely do that - I originally did it that way
but converted to notes because I want to make sure that I can
send out the applied mails if the push succeeds even if the
network is slow or spotty.

> I also have a local message-id <=> patchwork id mapping, and that means
> I can also do the patchwork state update based purely off the Link: tag.

...

> If only the patchwork maintainers weren't all volunteers they could get
> that implemented some time ;)

Indeed.

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 23:11                                             ` Doug Anderson
@ 2019-09-16 14:11                                               ` Christian Brauner
  2019-09-16 17:43                                               ` Al Viro
  1 sibling, 0 replies; 105+ messages in thread
From: Christian Brauner @ 2019-09-16 14:11 UTC (permalink / raw)
  To: Doug Anderson, Dmitry Vyukov
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov

On Mon, Aug 26, 2019 at 04:11:12PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Mon, Aug 26, 2019 at 4:02 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> >
> > On Mon, Aug 26, 2019 at 02:35:33PM -0700, Doug Anderson wrote:
> > > * This requires extra tooling that I think nobody will adopt.  People
> > > today already (accidentally) adopt Change-Id in the non-discardable
> > > portion.  I think it would be easier to get everyone currently
> > > removing Change-Id to start including it again than it will be to get
> > > everyone to change their tools to move it to the discardable portion.
> >
> > The reason why people Change-Id's exist in commits today is because of
> > tooling which is distributed as part of Gerrit.  That's why people are
> > deeply suspicious of any solution that involves Change-Id in the
> > non-discarded portion --- because the majority of Gerrit servers up
> > until now are behind corporate firewalls and since Gerrit servers have
> > robots.txt files, most Change-Id tend to be useless.
> >
> > If we come up with new tooling which is more useful, people will use
> > it.  If it's not useful and doesn't makes life easier, people won't.
> 
> Unfortunately the tooling won't come up until Change-Id is there and
> Change-Id can't be there till the tooling is there.  ;-)
> 
> 
> > On Mon, Aug 26, 2019 at 03:06:43PM -0700, Doug Anderson wrote:
> > > 2. If, as I expect, Change-Id as part of the patch stays NAKed then I
> > > will modify the tools I use to post upstream (currently patman) to
> > > encode the Change-Id.  My naive proposal would be:
> > >
> > > Message-Id: ChangeId-YYYY-MMDD-HHMMSS-PatchNum
> > >
> > > If I try this and it works for me then I will post out and suggest
> > > that any other like-minded people encode Change-Id into Message-Id in
> > > a similar way.
> >
> > ... and I would expect patches with this would get NACK'ed because
> > they would be just as useless as Change-Id's are perceived to be
> > today.  People who are gaming the rules will tend not to looked upon
> > favorably; the same will apply to their patches.
> 
> Sigh.  Email is so hard to communicate over.  I'm not intending to
> include the Message-Id in the commit.  I'm intending to use the
> Change-Id _in_ the Message-Id.  The Message-Id already has a bunch of
> random characters in it.  Why not make them useful for something?
> 
> 
> > BTW, the Message-Id you've listed above is not legal, per RFC-5322.  A
> > msg-id has to look like a e-mail address (left-hand-side@example.com).
> > So something like this is legal as a message id:
> >
> > I3268f9036512c4378cde1da37e0612b43ed4d384@linux-review.googlesource.com
> 
> I think this is the same comment that Thomas Gleixner had.  I will
> certainly make sure my Message-Ids are formed correctly.  Thank you
> both for pointing this out to me.  Presumably I would have noticed it
> when actually trying to implement this but now I definitely will.
> 
> 
> > ... and indeed, that's more useful, because it tells us how to
> > interpret I3268f9036512c4378cde1da37e0612b43ed4d384 --- it's a
> > Change-Id assigned by the linux-review.googlesource.com Gerrit server.
> >
> > In contrast a bare "I3268f9036512c4378cde1da37e0612b43ed4d384" is
> > going to be presumed to be useless.  And in fact, a Google search for
> > this ID returns *nothing*.  Yet visiting the link
> > https://linux-review.googlesource.com/c/1158 actually returns
> > something useful.   That's why the latter is superior to the former.
> 
> Sure, except that in my case there is no gerrit server to provide a
> link to.  I use an upstream-first approach which means that all
> initial work is done with mailing lists.  There is no server to
> provide context to.  I think we are re-hashing old emails in this
> thread.
> 
> 
> > In summary,
> >
> > Not useful: (and will be probably nacked)
> >
> > Change-Id: I3268f9036512c4378cde1da37e0612b43ed4d384
> > Message-Id: I3268f9036512c4378cde1da37e0612b43ed4d384
> >
> > Useful:
> >
> > Link: https://linux-review.googlesource.com/c/1158
> > Link: https://lkml.kernel.org/r/20190826204407.17759-1-daniel.lezcano@linaro.org
> >
> > Not as useful: (people will prefer the Link example above)
> >
> > Message-Id: 20190826204407.17759-1-daniel.lezcano@linaro.org
> 
> Presumably all the above is because you thought I was including the
> Message-Id in the commit.  I'm not.  Locally I will have Change-Id in
> my commit.  The scripts I use to post to the mailing lists will strip
> the Change-Id out and use it to make the actual Message-Id.  I will

Hm, I've spoken in favour of the Link: approach for upstream purposes.
But I do see the point in making it possible for people to somehow have
a workflow involving change-ids that does not interfer with regular
upstream expectations, i.e. no Change-Ids in commit messages.

One thing that came up was to place stuff like Change-Id after the ---
which git format-patch would leave out. This still has the problem
though that a git merge will keep the stuff after the --- and so a git
tag followed by a git request-pull would have the stuff in there as well
afaict. So I wonder if you couldn't simply enable Gerrit to look for
stuff like Change-Ids in git notes. They wouldn't show up on merges and
pulls afaict...

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-08-26 23:11                                             ` Doug Anderson
  2019-09-16 14:11                                               ` Christian Brauner
@ 2019-09-16 17:43                                               ` Al Viro
  2019-09-16 18:05                                                 ` Doug Anderson
  1 sibling, 1 reply; 105+ messages in thread
From: Al Viro @ 2019-09-16 17:43 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

On Mon, Aug 26, 2019 at 04:11:12PM -0700, Doug Anderson wrote:

> Sigh.  Email is so hard to communicate over.  I'm not intending to
> include the Message-Id in the commit.  I'm intending to use the
> Change-Id _in_ the Message-Id.  The Message-Id already has a bunch of
> random characters in it.  Why not make them useful for something?

*blink*

I must be misreading you; are you *really* suggesting to update
every MUA people are using?  Or researching and documenting
the ways to control said MUAs to achieve the effect.

I don't know how to get that in mutt(1), TBH.  And then there are
poor sods who use browsers/evolution/pine/whatnot for that...
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

^ permalink raw reply	[flat|nested] 105+ messages in thread

* Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
  2019-09-16 17:43                                               ` Al Viro
@ 2019-09-16 18:05                                                 ` Doug Anderson
  0 siblings, 0 replies; 105+ messages in thread
From: Doug Anderson @ 2019-09-16 18:05 UTC (permalink / raw)
  To: Al Viro
  Cc: Joel Fernandes, Barret Rhoden, ksummit, Greg Kroah-Hartman,
	Jonathan Nieder, Tomasz Figa, Han-Wen Nienhuys, Theodore Tso,
	David Rientjes, Dmitry Torokhov, Dmitry Vyukov

Hi,

On Mon, Sep 16, 2019 at 10:43 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Mon, Aug 26, 2019 at 04:11:12PM -0700, Doug Anderson wrote:
>
> > Sigh.  Email is so hard to communicate over.  I'm not intending to
> > include the Message-Id in the commit.  I'm intending to use the
> > Change-Id _in_ the Message-Id.  The Message-Id already has a bunch of
> > random characters in it.  Why not make them useful for something?
>
> *blink*
>
> I must be misreading you; are you *really* suggesting to update
> every MUA people are using?  Or researching and documenting
> the ways to control said MUAs to achieve the effect.
>
> I don't know how to get that in mutt(1), TBH.  And then there are
> poor sods who use browsers/evolution/pine/whatnot for that...

In general I think most people send patches with git-send-email.  If
you use git-send-email you can simply add a Message-Id into your patch
files before passing them to git-send-email and it'll use that.  If
you use mutt to directly send a patch then, right, it won't get a
message ID like this.  I think expecting 100% adoption is impossible,
so for now I'm hoping to get sufficient adoption that it could be
worth it for someone to do the tools integration.

FYI: I personally use patman to send my patches (which eventually
passes them to git-send-email).  The patman change to setup the
Message-Id is at:

https://patchwork.ozlabs.org/patch/1157266/

Johannes Berg also responded to my patch providing a proof of concept
way to use a git hook.


NOTE: for responses to patches (where it's more likely people will use
mutt) there is no need for magic Message-Id.  There are already plenty
of ways to track responses to emails.

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

^ permalink raw reply	[flat|nested] 105+ messages in thread

end of thread, back to index

Thread overview: 105+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-22 23:39 [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits Doug Anderson
2019-08-23  0:03 ` Brendan Higgins
2019-08-23  0:17 ` Linus Torvalds
2019-08-23  0:30   ` Olof Johansson
2019-08-23  0:43     ` Guenter Roeck
2019-08-23  0:45       ` Olof Johansson
2019-08-23  1:05         ` Olof Johansson
2019-08-23  1:09           ` Dmitry Torokhov
2019-08-23  1:36         ` Theodore Y. Ts'o
2019-08-23  2:58           ` Linus Torvalds
2019-08-23  3:03             ` Linus Torvalds
2019-08-23 13:15               ` Sean Paul
2019-08-23 15:18                 ` Theodore Y. Ts'o
2019-08-23 15:31                   ` Sean Paul
2019-08-23 15:48                     ` Thomas Gleixner
2019-08-23 16:19                       ` Dmitry Torokhov
2019-08-23 16:35                         ` Joel Fernandes
2019-08-23 16:45                           ` Doug Anderson
2019-08-23 16:54                             ` Joel Fernandes
2019-08-23 18:00                               ` Doug Anderson
2019-08-23 19:08                                 ` Joel Fernandes
2019-08-23 19:15                                   ` Joel Fernandes
2019-08-23 19:23                                     ` Thomas Gleixner
2019-08-23 19:31                                       ` Joel Fernandes
2019-08-24 16:53                                   ` Doug Anderson
2019-08-23 16:46                           ` Dmitry Torokhov
2019-08-23 19:17                             ` Thomas Gleixner
2019-08-23 19:38                               ` Laurent Pinchart
2019-08-23 21:15                                 ` Thomas Gleixner
2019-08-23 21:25                                   ` Mark Brown
2019-08-24 23:13                                   ` Theodore Y. Ts'o
2019-08-25  7:09                                     ` Thomas Gleixner
2019-08-26 22:05                                       ` Thomas Gleixner
2019-08-28  8:50                                         ` Thomas Gleixner
2019-08-23 20:02                               ` Christian Brauner
2019-08-24 16:34                                 ` Doug Anderson
2019-08-24 18:11                                   ` Linus Torvalds
2019-08-24 23:04                                     ` Theodore Y. Ts'o
2019-08-25  3:11                                       ` Greg Kroah-Hartman
2019-08-27 10:51                                         ` Mark Brown
2019-09-09  8:14                                           ` Michael Ellerman
2019-09-09 12:09                                             ` Mark Brown
2019-08-26 17:13                                     ` Doug Anderson
2019-08-26 17:30                                       ` Joel Fernandes
2019-08-26 21:35                                         ` Doug Anderson
2019-08-26 21:51                                           ` Thomas Gleixner
2019-08-26 22:06                                             ` Doug Anderson
2019-08-26 22:19                                               ` Thomas Gleixner
2019-08-26 23:02                                           ` Theodore Y. Ts'o
2019-08-26 23:11                                             ` Doug Anderson
2019-09-16 14:11                                               ` Christian Brauner
2019-09-16 17:43                                               ` Al Viro
2019-09-16 18:05                                                 ` Doug Anderson
2019-08-26 23:43                                             ` Thomas Gleixner
2019-08-28 12:34                                               ` Christian Brauner
2019-08-27  0:29                                             ` Dmitry Vyukov
2019-08-27  6:06                                               ` Thomas Gleixner
2019-08-27 13:24                                                 ` Dmitry Vyukov
2019-08-27 13:48                                                   ` Greg Kroah-Hartman
2019-08-27 14:01                                                     ` Guenter Roeck
2019-08-27 14:09                                                       ` Thomas Gleixner
2019-08-27 15:33                                                         ` Greg Kroah-Hartman
2019-08-27 15:42                                                           ` Thomas Gleixner
2019-08-27 18:55                                                           ` Konstantin Ryabitsev
2019-08-27 19:53                                                             ` Greg Kroah-Hartman
2019-08-27 21:34                                                               ` Joel Fernandes
2019-08-27 21:38                                                                 ` Joel Fernandes
2019-08-28  9:08                                                                 ` Greg Kroah-Hartman
2019-08-28  9:25                                                                   ` Jani Nikula
2019-08-28 10:04                                                                   ` Martin K. Petersen
2019-08-28 10:53                                                                     ` Thomas Gleixner
2019-08-28 12:46                                                                       ` Martin K. Petersen
2019-08-28 10:42                                                                   ` Mark Brown
2019-08-28 11:41                                                                     ` Greg Kroah-Hartman
2019-08-28 12:22                                                                   ` Christian Brauner
2019-08-28 12:38                                                                   ` Joel Fernandes
2019-08-28 13:58                                                                     ` Theodore Y. Ts'o
2019-08-28 20:39                                                                       ` Doug Anderson
2019-08-28 20:46                                                                         ` Johannes Berg
2019-08-28 21:00                                                                           ` Doug Anderson
2019-08-28 22:15                                                                         ` Rob Herring
2019-08-27 17:34                                                       ` Geert Uytterhoeven
2019-08-27 18:50                                                         ` Guenter Roeck
2019-08-27 14:06                                                   ` Thomas Gleixner
2019-08-27  7:33                                               ` Geert Uytterhoeven
2019-08-27 13:30                                                 ` Dmitry Vyukov
2019-08-27 14:28                                                   ` Paul E. McKenney
2019-08-27 15:06                                                     ` Thomas Gleixner
2019-08-27 15:25                                                       ` Paul E. McKenney
2019-08-28  8:57                                                         ` Dan Carpenter
2019-08-23 15:49                     ` Doug Anderson
2019-08-23 15:54                       ` Thomas Gleixner
2019-08-23 15:59                         ` Thomas Gleixner
2019-08-23 16:38                           ` Doug Anderson
2019-08-23 16:50                             ` Andrew Lunn
2019-08-23 17:50                               ` Doug Anderson
2019-08-23 18:10               ` Konstantin Ryabitsev
2019-08-26 22:19               ` Paul Mackerras
2019-08-27  7:02                 ` Stephen Rothwell
2019-08-23  9:09             ` Vlastimil Babka
2019-08-23 12:48               ` Bhaskar Chowdhury
2019-08-23  1:01   ` Dmitry Torokhov
2019-08-23  1:07   ` Doug Anderson
2019-08-23  1:18     ` Joel Fernandes
2019-09-05  8:12 ` Eric Wong

Ksummit-Discuss Archive on lore.kernel.org

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

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

Example config snippet for mirrors

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


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