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

Paul E. McKenney
2019-08-27T14:28:32Z

On Tue, Aug 27, 2019 at 06:30:11AM -0700, Dmitry Vyukov via Ksummit-discuss wrote:
> On Tue, Aug 27, 2019 at 12:33 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> >
> > 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>"?).
>
> A change identification scheme would need to solve all of these. E.g.
> non-committed changes look more problematic for anything that uses
> commit hashes...
>
> > > 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.
>
> It's not me, it's everybody ;)
> If I am reading git help correctly, this won't handle changes with
> more than 1 version. Also maintainers will be prohibited from doing
> any changed to patches during commit.

Or we are required to add more Link: tags or other annotations describing
what we changed and why.

Thanx, Paul