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

[Doug Anderson <dianders@chromium.org>]

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