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 184DBFB6 for ; Fri, 23 Aug 2019 00:43:36 +0000 (UTC) Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9A6AB7FB for ; Fri, 23 Aug 2019 00:43:35 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id w16so5148955pfn.7 for ; Thu, 22 Aug 2019 17:43:35 -0700 (PDT) Sender: Guenter Roeck To: Olof Johansson , Linus Torvalds References: From: Guenter Roeck Message-ID: Date: Thu, 22 Aug 2019 17:43:32 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 8/22/19 5:30 PM, Olof Johansson wrote: > On Thu, Aug 22, 2019 at 5:17 PM 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_. >> >>> * 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 note that how when it comes to message ID's we encourage them in a >> form that actually also helps look that information up, ie the >> preferred form isn't just the message ID (although that exists), it's >> a link like >> >> Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org >> >> instead of >> >> Message-ID: 20190723065733.4899-5-leon@kernel.org >> >> even though technically they have just as much actual information in theory. >> >> Do you see people complaining about that kind of UUID? No. Because it >> gives useful information to the project, and when something happens, >> people can look things up and _use_ that kind of UUID. > > For the actual open projects, the answer to this might be relative > easy: Most gerrit instances can feed a mailing list with emails of > both the initial patch, and later comments. > > Said emails would obviously have a Message-ID, and if the list is > added to lore, it can be referenced there. > > Note, even if the Change-Id had a full URL, there would be no archival > guarantee in the same way as lore gives us, so that approach alone > isn't useful. A URL to a "forever" mailing list archive seems like the > most stable possible reference. > > This doesn't address the full issue Doug was looking to solve, which > is the reverse mapping of "posted patch" to "previous version of the > patch". Patchwork tries to guess this, but it's best effort. I don't > have a great answer to this, besides possibly in-reply-to threading > and associating back that way via the email trail. > Wouldn't a direct link to the Gerrit instance solve the problem ? After all, Link: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1759334 points to the same Gerrit entry as Change-Id: I5a2e33424e7fb19fed13afb854ae6546ef9bfa35 and there would be no need to look anything up. Guenter