On Wed, Jul 20, 2022 at 03:21:44PM -0400, Konstantin Ryabitsev wrote:
> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx
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
