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

Theodore Y. Ts'o
2019-08-23T15:18:51Z

On Fri, Aug 23, 2019 at 09:15:30AM -0400, Sean Paul wrote:
> Only if you've uploaded the patch somewhere before sending it to the
> mailing list. I think this would satisfy the Gerrit crowd, since
> they're presumably uploading the patch to Gerrit, getting some review
> on it and then sending it upstream. They will have a link. If you're
> just interested in being archival tool friendly, you probably just
> want to add some uuid cookie to the patch and post it directly to the
> mailing list.

And this is why I think something like one of the two:

Link: https://linux-review.googlesource.com/c/1158
Link: https://linux-review.googlesource.com/q/I3268f9036512c4378cde1da37e0612b43ed4d384

... is a better choice.

The Link tag, unlike the Change-Id: hidden amongst the diffstat,
allows any patch review comments which are made via Gerrit to be
accessible to the public. The main reason why I suggested the first
as opposed to the second initially is that one of the pushbacks
against the "Change-Id: " header was that the
"I3268f9036512c4378cde1da37e0612b43ed4d384" portion was ugly.

Yes, that's purely an aesthetics argument, but in terms of human
emotional acceptance, that's important. The first is arguably better
than:

Link: https://bugzilla.kernel.org/show_bug.cgi?id=200847

... which people are already willing to accept.

There are some advantages to the second, in that we don't have to
contact Gerrit to assign the small integer number. Either way,
though, it should easy to teach Gerrit how to interpret either instead
of the "Change-Id:" tag, and for publically accessible Gerrit
instances, the Link: tag is strictly superior. It allows you to know
which Gerrit server to contact to find the review history, and it
becomes obvious whether that Gerrit server is publicaly accessible, or
if it is hidden behind a corporate firewall.

Cheers,

- Ted