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

Dmitry Vyukov
2019-08-27T13:24:53Z

On Mon, Aug 26, 2019 at 11:06 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Mon, 26 Aug 2019, Dmitry Vyukov wrote:
> > A somewhat related point re UUID/Change-ID.
> > For syzbot (or any other bug tracking system) we want to associate
> > bugs with fixes. It turned out there is no good identity of a change
> > that we could use. Commit hash is an obvious first thing to consider,
> > but (1) it changes in linux-next, (2) sometimes the change is not
> > committed yet when we do the association, (3) it is different when
> > backported to LTS (so not possible to say if a fix is in that stable
> > tree or not).
> > We decided to use commit subject, which works to some degree, but also
> > has problems: (1) not necessary unique, (2) sometimes people change
> > subject during backporting (e.g. prepend some prefix), (3) has all the
> > same problems of email clients messing with text (e.g. I can't issue
> > #syz fix command for loo long commit subjects with my email client).
> > Some real UUID/Change-ID would solve all of these problems by giving
> > us capability to refer to changes rather than a commit in a particular
> > tree only.
>
> If we adopt the Link: ..../$MSG tag widely then you have a UUID.

Is there a way to ensure that everybody will generate right IDs
(ChangeID-Version) and then a link in canonical form will be included
into commit? As far as I understand this is not possible with the
current kernel tooling, as this aspect is not under control of any
unified tooling.
I see different maintainers use links to different archive web sites.
Also sometimes Link is present for other reasons (e.g. link to bug
report).
The link will need to be added by every developer (rather than
maintainer) so that it's available before the change is committed
anywhere.
Though, most of these are problems for any other change identification scheme...