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

[Olof Johansson <olof@lixom.net>]

On Thu, Aug 22, 2019 at 5:17 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Thu, Aug 22, 2019 at 4:40 PM Doug Anderson <dianders@chromium.org> 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.


-Oloif