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 11AEA15AC for ; Tue, 27 Aug 2019 14:07:00 +0000 (UTC) Received: from Galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8EDC7710 for ; Tue, 27 Aug 2019 14:06:59 +0000 (UTC) Date: Tue, 27 Aug 2019 16:06:55 +0200 (CEST) From: Thomas Gleixner To: Dmitry Vyukov In-Reply-To: Message-ID: References: <20190826230206.GC28066@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Tue, 27 Aug 2019, Dmitry Vyukov wrote: > 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 What? You want to enforce that on every single person on the planet who submits patches for the kernel? Good luck with that.