Re: Feature request: provide a persistent IDs on a commit

From: Theodore Ts'o <tytso@mit.edu>
Date: Jul 20, 2022, 22:10 UTC
Message-ID: <Yth9TCCEXfmagaaw@mit.edu>
In-Reply-To: <20220720192144.mxdemgcdjxb2klgl@nitro.local>

On Wed, Jul 20, 2022 at 03:21:44PM -0400, Konstantin Ryabitsev wrote:

Show 5 quoted lines

> The kernel community has repeatedly rejected per-patch Change-id trailers
> because they carry no meaningful information outside of the gerrit system on
> which they were created. Seeing a Change-Id trailer in a commit tells you
> nothing about the history of that commit unless you know the gerrit system on
> which this patch was reviewed (and have access to it, which is not a given).

The "no meaningful information outside of the gerrit system" is the key. This was extensively discussed in the ksummit-discuss@lists.linux-foundation.org mailing list in late August 2019, subject line "Allowing something Change-Id (or something like it) in kernel commits". Quoting from Linus Torvalds:

    From: Linus Torvalds
    Date: Thu, 22 Aug 2019 17:17:05 -0700
    Message-Id: CAHk-=whFbgy4RXG11c_=S7O-248oWmwB_aZOcWzWMVh3w7=RCw@mail.gmail.com

    No. That's not it at all. It's not "dislike gerrit".

    It's "dislike pointless garbage".

    If the gerrit database is public and searchable using the uuid, then
    that would make the uuid useful to outsiders. And instead of just
    putting a UUID (which is hard to look up unless you know where it came
    from), make it be that "Link:" that gives not just the UUID, but also
    gives you the metadata for that UUID to be looked up.

    But so far, in every single case the uuid's I've ever seen have been
    pointless garbage, that aren't useful in general to public open source
    developers, and as such shouldn't be in the git tree.

    See the difference?

    So if you guys make the gerrit database actually public, and then
    start adding "Link: ..." tags so that we can see what they point to, I
    think people will be more than supportive of it.

    But if it's some stupid and pointless UUID that is useful to nobody
    outside of google (or special magical groups of people associated with
    it), then I will personally continue to be very much against it.

So.... imagine if we had some kind of search service, maybe homed at lore.kernel.org, where given a particular "Change Id" --- and it could look either like a Gerrit-style Change-Id or something else like a URL or URL-like (it matters not) the search service could give you a list of:

  * All mailing list threads where the body contained the "Change-Id:
    XXX" id, so we could find the previous versions of the commit, and
    the reviews that took place on a mailing list.  (And this could be
    either a pointer to lore.kernel.org and/or a patchwork URL.)

  * All URL's to public gerrit servers where that patch may have been reviewed.

  * A list of git Commit ID's from a set of "interesting" git trees
    (e.g., the upstream Linux tree, the Long Term Stable trees, maybe
    some other interesting trees ala Android Common, etc.

If we had such a thing, as opposed to something that only worked in a closed private garden like an internal Gerrit server sitting behind a corporate firewall, even if the patch initially was developed in a closed private Gerrit ecosystem --- if the moment it was published for external upstream review, it would get captured by this search service, then the Change ID would be useful. And if that Change ID could also be used to find out how the patch was ported to various stable or productg trees, then it would be even more useful --- and then people would probably find it to be useful, and resistance to having a per-commit Change-ID would probably drop, or perhaps, even enthusiastically embraced, because people could actually see the *value* behind it.

To do this, we would need to have various tools, such as Patchwork, Gerrit, Git, public-inbox, etc., treat Change-ID as a first-class indexed object, so that you could quickly map from a Change-ID to a git commit in a particular git tree (if present), or to set of public-inbox URL's, or a set of patchwork URL's, etc.

And then we would need some kind of aggregation service which would aggregate the information from all of the various sources (public-inbox, git, Gerrit, Patchwork, etc.) and then gave users a single "front door" where they could submit a Change-Id, and find all the patch history, patch review comments, and later, patch backports and forward ports.

The question is ---- is this doable?   And who will do the work?   :-)

    	     	     	     	       - Ted