Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits

[Joel Fernandes <joelaf@google.com>]

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