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 9EAD32133 for ; Mon, 26 Aug 2019 17:31:11 +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 54D471FB for ; Mon, 26 Aug 2019 17:31:10 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id 201so14682056qkm.9 for ; Mon, 26 Aug 2019 10:31:10 -0700 (PDT) MIME-Version: 1.0 References: <20190823013619.GA8130@mit.edu> <20190823151843.GH8130@mit.edu> <20190823161947.GA112509@dtor-ws> <20190823164602.GB112509@dtor-ws> In-Reply-To: From: Joel Fernandes Date: Mon, 26 Aug 2019 13:30:57 -0400 Message-ID: To: Doug Anderson Content-Type: text/plain; charset="UTF-8" Cc: Barret Rhoden , Dmitry Torokhov , ksummit , Greg Kroah-Hartman , Jonathan Nieder , Tomasz Figa , Han-Wen Nienhuys , Theodore Tso , Dmitry Vyukov , David Rientjes 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 1:13 PM Doug Anderson wrote: > On Sat, Aug 24, 2019 at 11:11 AM Linus Torvalds > wrote: > > > > On Sat, Aug 24, 2019 at 9:35 AM Doug Anderson wrote: > > > > > > I have no gerrit server involved when I submit patches to the list. I do: > > > > > > 1. Write patch on my local machine. > > > 2. Post v1 to mailing list. > > > 3. Make changes. > > > 4. Post v2 to mailing list. > > > 5. Make changes. > > > 5. Post v3 to mailing list. > > > > > > I have never uploaded to a gerrit in this process. THERE IS NO GERRIT LINK! > > > > First off, there *is* a link - just use the mailing list email link > > (preferably for the cover letter - so that a whole series has _one_ > > ID, not separate ID's for every patch) just like everybody else does, > > which also means that you get the history of actual other developers > > replying to it (including after it has been committed). > > > > The first time it gets magically and reliably created for you without > > you having to do a single thing. The second time, you just look it up. > > The key problem here is that it requires the committer to look > something up and perform a manual step. IMO this means that the > adoption rate will be near to zero. The reason that Change-Id > _doesn't_ require a manual step is that it's in your local commit > message and thus automatically stays there. Thus inaction (leaving > the Change-Id alone as you spin the patch) produces the ideal > behavior. Sure, but.. > > > > So stop arguing for UUID's. They are fundamentally a bad idea. > > > > The *only* actual valid reason I have ever seen for UUID's (and yes, > > this is not the first time they've been brought up, which is why I > > hate them with a passion) is to use it as a magic link inside some > > vendors private database when that vendor doesn't want to expose any > > actual real information. > > What I see here is: > > 1. A valid reason to have a UUID is to help a machine that's > processing data. Specifically UUIDs are well-formed and easy for a > machine to understand (unlike a link which could point to anything). I don't think a "link could point to anything" is a good argument against links. A link to lore.kernel.org/r/ should point to only one thing. > 2. In the past you don't like UUIDs because the machines making sense > of them are private. > > In this thread I am trying to argue that if we allow UUIDs in the > public email lists that anyone will be able to create a useful and > public database linking patch versions together. Did you read all the emails that said these can be inserted into the discardable part of a patch? Enforcing it on everyone in the community is impossible. > > In other words: UUID's are bad and pointless. Their only "valid" use > > is explicitly against the whole point of open development. > > > > Use an actual open standard instead: a web link. It can be anything. > > The "It can be anything" is the problem with links. Computers trying I think he meant it can be any link. But what a link points to (lore.kernel.org/r/) largely should not change. > NOTE: from reading all of this, one thing that I should probably be > able to do myself is: > > 1. Keep having Change-Id in my patches on my local computer. > > 2. Have the scripts I use to post upstream (which strips Change-Id out > before posting) encode the Change-Id into the Message-Id in a way that > it could be recovered, like: > > Message-Id: Ic3e54798e4aeaa862b2e8eebcbbcef4e51ccae19-2018-1231-235959-1 Why not just put whatever-ID in the discardable part of your patch as others have also pointed, and move on? thanks, - Joel