On Thu, Nov 28, 2024 at 09:19:59AM +0100, Mauro Carvalho Chehab wrote: > Em Wed, 27 Nov 2024 12:59:58 +0100 Hans Verkuil escreveu: > > > > I find the GPG signature requirement to be borderline ridiculous. The > > > first message you're giving to committers is that you distrust them so > > > much that you want them to sign an agreement with their blood > > > (figuratively speaking). I don't think it's a very good approach to > > > community building, nor does it bring any advantage to anyone. > > > > I kind of agree with Laurent here. Is the media-committers mailinglist > > publicly archived somewhere? I think it is sufficient if this is posted > > to a publicly archived mailinglist. That could be linux-media, I would be > > fine with that. But media-committers would be more appropriate, but only > > if it is archived somewhere. > > > > If we want a GPG key, what would we do with it anyway? > > Every time I send pull requests upstream, I sign the PR tag with my GPG > key: > > https://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git/tag/?h=media/v6.13-2 > > This is a requirement from the top maintainer. Requiring it is pretty much > standard at the Kernel community, and wasn't anything similar "to sign with > my blood" (using your words). > > It is not just a random GPG key: it is a trusted key as stated at this patch: > > "a PGP key cross signed by other Kernel and media developers" > ... > For more details about PGP sign, please read > Documentation/process/maintainer-pgp-guide.rst and > :ref:`kernel_org_trust_repository`." > > If you see the last link, we're talking about a GPG signature inside > kernel.org web of trust. > > Heh, all PRs we receive are signed with GPG keys that we trust, including > PRs from you. We need to keep doing it with the new workflow. > > That reminds that there are still a gap there: the e-mail from the > newcoming committer shall contain something like: > > "I'll be using this username to commit patches at media-committers: > https://gitlab.freedesktop.org/<username>" > > I'll add it to the next version. I don't mind much either way, but as we're using gitlab for the shared tree, we could also do the same as drm-misc and handle this through a gitlab issue instead of an e-mail. That advantage is that we'll ensure the person has a gitlab account. -- Regards, Laurent Pinchart
