Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits

From: Joel Fernandes <joelaf@google.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Barret Rhoden <brho@google.com>,
	Dmitry Torokhov <dtor@chromium.org>,
	ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonathan Nieder <jrn@google.com>,
	Tomasz Figa <tfiga@chromium.org>,
	Han-Wen Nienhuys <hanwen@google.com>,
	Theodore Tso <tytso@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	David Rientjes <rientjes@google.com>
Subject: Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
Date: Mon, 26 Aug 2019 13:30:57 -0400	[thread overview]
Message-ID: <CAJWu+op476JWYqbT_dLaW7THqiJUvHPbOjeC=PUT5rzkGv4O1A@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=VJt4+XRj59h6tmma5LfU52E_6QOSQVjh3T3M+1V=eMsQ@mail.gmail.com>

On Mon, Aug 26, 2019 at 1:13 PM Doug Anderson <dianders@chromium.org> wrote:
> On Sat, Aug 24, 2019 at 11:11 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Sat, Aug 24, 2019 at 9:35 AM Doug Anderson <dianders@chromium.org> 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/<message-id> 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/<message-id>) 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