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 B67F21952 for ; Tue, 27 Aug 2019 17:34:59 +0000 (UTC) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2AF00710 for ; Tue, 27 Aug 2019 17:34:59 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id 16so15594888oiq.6 for ; Tue, 27 Aug 2019 10:34:59 -0700 (PDT) MIME-Version: 1.0 References: <20190826230206.GC28066@mit.edu> <20190827134836.GB25038@kroah.com> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 27 Aug 2019 19:34:45 +0200 Message-ID: To: Guenter Roeck Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: Joel Fernandes , Barret Rhoden , ksummit , Greg Kroah-Hartman , Jonathan Nieder , Tomasz Figa , Han-Wen Nienhuys , Theodore Tso , David Rientjes , Dmitry Torokhov , Dmitry Vyukov 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: , Hi G=C3=BCnter, On Tue, Aug 27, 2019 at 4:01 PM Guenter Roeck wrote: > On 8/27/19 6:48 AM, Greg Kroah-Hartman wrote: > > On Tue, Aug 27, 2019 at 06:24:36AM -0700, 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 al= so > >>>> has problems: (1) not necessary unique, (2) sometimes people change > >>>> subject during backporting (e.g. prepend some prefix), (3) has all t= he > >>>> 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 particul= ar > >>>> 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. > > > > For subsystems I maintain, I am already adding the Link: tag to > > lore.kernel.org with the message id in it. That is automatically added > > by my scripts. > > > >> Though, most of these are problems for any other change identification= scheme... > > > > Note, we have 4000+ developers every year, it's hard enough to get them > > all to agree on major things, let alone crazy stuff like this :) > > > > Is it really that crazy ? > > I have to use a combination of subject analysis and patch content analysi= s > using fuzzy text / string comparison, combined with an analysis of the pa= tch > description, to answer a simple question: Is this patch upstream, and wha= t is > its upstream SHA ? Having a UUID tag would make this a simple and I typically use "git cherry -v" to check if a patch is upstream. Yes, this may miss a patch that was changed. But that can be a good thing. > straightforward operation. What is crazy is having to do all this analysi= s. What happens to the UUID when a patch is split in two parts? If a part is applied with the same UUID, that would give the false impressi= on that the original full patch was applied. At least rebasing (using git rebase) your submissions against upstream will keep the part that still hasn't been applied. Gr{oetje,eeting}s, Geert --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds