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

Doug Anderson
2019-08-26T22:06:56Z

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