From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E2ACD150D for ; Tue, 27 Aug 2019 13:24:53 +0000 (UTC) Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DEC5A8A7 for ; Tue, 27 Aug 2019 13:24:51 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id d23so16969793qko.3 for ; Tue, 27 Aug 2019 06:24:51 -0700 (PDT) MIME-Version: 1.0 References: <20190826230206.GC28066@mit.edu> In-Reply-To: From: Dmitry Vyukov Date: Tue, 27 Aug 2019 06:24:36 -0700 Message-ID: To: Thomas Gleixner Content-Type: text/plain; charset="UTF-8" Cc: Joel Fernandes , Barret Rhoden , ksummit , Greg Kroah-Hartman , Jonathan Nieder , Tomasz Figa , Han-Wen Nienhuys , Theodore Tso , David Rientjes , Dmitry Torokhov Subject: Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Aug 26, 2019 at 11:06 PM Thomas Gleixner 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...