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 2A0FE10F5 for ; Fri, 23 Aug 2019 01:01:52 +0000 (UTC) Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B63627FB for ; Fri, 23 Aug 2019 01:01:51 +0000 (UTC) Received: by mail-pl1-f194.google.com with SMTP id w11so4030322plp.5 for ; Thu, 22 Aug 2019 18:01:51 -0700 (PDT) Date: Thu, 22 Aug 2019 18:01:46 -0700 From: Dmitry Torokhov To: Linus Torvalds Message-ID: <20190823010146.GB139536@dtor-ws> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: , On Thu, Aug 22, 2019 at 05:17:05PM -0700, Linus Torvalds wrote: > On Thu, Aug 22, 2019 at 4:40 PM Doug Anderson wrote: > > > > The Linux kernel has always viewed these Change-Id tags as obnoxious > > and useless spam. Anyone who accidentally leaves a Change-Id in their > > patch when posting to the mailing list is told to please re-post their > > patch without the Change-Id. In this email, I will attempt to argue > > that the Linux kernel ought to relax this restriction and allow > > (possibly even encourage) Change-Ids. > > No. > > Not without some ground rules. > > > To begin with, let me make sure we're on the same page about what > > Change-Ids are. As I understand it: > > > > * A change ID is much alike a UUID. It is locally generated on a > > developer's computer and is (in theory) unique across the universe. > > Completely irrelevant. > > The point of an UUID is not just that it's unique, but THAT YOU CAN > LOOK SOMETHING UP USING IT! > > A "change ID" that I can't use to look anything up with is completely > pointless and should be removed from kernel history. > > But if you have something unique that is actually useful for looking > things up, then by all means. But it needs to be useful for > _everybody_. It can be used by anybody. At the barest minimum, one can simply google it and get results from emails sent to LKML and other lists. Maybe down the road patchwork will learn to use it. BTW, I am not sure if we want a patch ID or series ID that is stable across patch series. > > > * When a developer keeps the same Change-Id across two patches they > > are making the assertion that the two patches are either the same or > > should be treated as two versions of the same logical change. > > .. and we have better ways to do that. > > For example, we are actively encouraging things like message ID's > (which are _also_ a form of locally generated UUID, they just are more > than the silly purely numerical one). > > That gives you the origin of something, but it also gives you the > development history and context. But not all of it, as when somebody posts v2, v3, v4 of the patch series the emails will generate new message IDs, so we lose connection to the old discussions. With new unique ID that is preserved for the entire lifetime of patch series it is much easier to locate all relevant data. Thanks. -- Dmitry