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

Greg Kroah-Hartman
2019-08-28T09:08:41Z

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