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

[Christian Brauner <christian.brauner@ubuntu.com>]

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