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:45 PM Olof Johansson <olof@lixom.net> wrote:
>
> On Thu, Aug 22, 2019 at 5:43 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On 8/22/19 5:30 PM, Olof Johansson wrote:
> > > 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.
> > >
> >
> > 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.
>
> Nope, for the same reason I already mentioned: In 2 years when Google
> deprecates Chromium and EOL's the product and project (see: Reader,
> Google+, Youtube messaging), there will be no way to get to the
> history. (I know, unlikely in this case, but URLs move without
> redirects, etc).
>
> Lore solves that, since it's externally archived.

Actually, it seems like the outgoing email already has suitable headers.

I looked up a random review, and viewed raw message:

https://groups.google.com/a/chromium.org/forum/#!original/chromium-os-reviews/Y2R_LLKytQw/M0TRRzfoAgAJ

X-Gerrit-Change-Id: I50d72612569743198825afdf41200c15db759076
X-Gerrit-Change-Number: 1762035
X-Gerrit-ChangeURL:
<https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1762035>
X-Gerrit-Commit: 5b7dff2b2cb0b1a8769a53d59e387772ae569243

Since that would be captured in a mail archive, you could easily get
it from there if needed.

Based on this, there's no reason to use opaque Change-Id, all the
functionality needed can be reached through the mail URLs we already
agreed are reasonable to use.


(Someone should maybe tell Hao that he has the email address
misspelled in his S-o-b).


-Olof