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

Geert Uytterhoeven
2019-08-27T07:33:54Z

Hi Dmitry,

On Tue, Aug 27, 2019 at 2:30 AM Dmitry Vyukov via Ksummit-discuss
<ksummit-discuss@lists.linuxfoundation.org> 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).

For (3): LTS commits have "commit <sha1> upstream" in their description
(perhaps some have "cherry picked from commit <sha1>"?).

> 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.

"git patch-id --stable <sha1>" may help, too.

For quick lookups, you need to generate/append to an index regularly.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds