Re: [RFD] Explicitly documenting patch submission

Matt Mackall
2004-05-23T18:03:21Z

On Sun, May 23, 2004 at 05:35:10PM +0200, Arjan van de Ven wrote:
> On Sun, May 23, 2004 at 08:25:40AM -0700, Greg KH wrote:
> > On Sun, May 23, 2004 at 10:02:17AM +0200, Arjan van de Ven wrote:
> > > On Sun, 2004-05-23 at 08:46, Linus Torvalds wrote:
> > > > Hola!
> > > >
> > > > This is a request for discussion..
> > >
> > > Can we make this somewhat less cumbersome even by say, allowing
> > > developers to file a gpg key and sign a certificate saying "all patches
> > > that I sign with that key are hereby under this regime". I know you hate
> > > it but the FSF copyright assignment stuff at least has such "do it once
> > > for forever" mechanism making the pain optionally only once.
> >
> > I don't think that adding a single line to ever patch description is
> > really "pain". Especially compared to the FSF proceedure :)
> >
> > Also, gpg signed patches are a pain to handle on the maintainer's side
> > of things, speaking from personal experience. However our patch
> > handling scripts could probably just be modified to fix this issue, but
> > no one's stepped up to do it.
>
> I'll buy that
>
> > And we'd have to start messing with the
> > whole "web of trust" thing, which would keep us from being able to
> > accept a patch from someone in a remote location with no way of being
> > able to add their key to that web, causing _more_ work to be done to get
> > a patch into the tree than Linus's proposal entails.
>
> But I don't buy this. No web of trust is needed if all that is happening is
> filing a form ONCE saying "all patch submissions signed with THIS key are
> automatically certified". That doesn't prevent non-gpg users from using the
> proposed mechanism nor involves web of trust metrics.

a) without the web of trust, it's not much stronger than the original
method
b) it's a second method so signing off is no longer a uniform process
c) it requires tools and a database
d) it adds significant amounts of cruft to patches
e) said cruft is fragile and won't survive minor edits along the way

That last point is key - we can't propagate a GPG signature upstream
_with revisions_. Trivial revisions of the form 'rediff against latest
kernel' are to be assumed.

--
Mathematics is the supreme nostalgia of our time.