qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] why restrict pull reqs to signed tags?


From: David Woodhouse
Subject: Re: [Qemu-devel] why restrict pull reqs to signed tags?
Date: Wed, 9 Mar 2016 14:13:54 -0000
User-agent: SquirrelMail/1.4.22-15.fc21

> On 9 March 2016 at 20:09, David Woodhouse <address@hidden> wrote:
>> Yeah, but the important criterion is *who* the thing comes from (and
>> again, a signed git tag is just as good as a set of signed emails).
>
> Well, it's also important to me that it's easy to apply stuff
> and that it comes in a single lump that's large enough that I
> don't have a lot of overhead in processing it. Sure, you could
> gpg sign individual patch mails and then check signatures when
> doing git am, but I don't do that because it would be a complete
> pain (and I'm not sure git has built-in tooling for doing it
> the way it does with gpg signed tags and merges). So I definitely
> would bounce an attempt by a submaintainer to send me stuff
> as a pile of signed patchmails.

Sure,  pull requests are better than email in fairly much every way :)

>> It *isn't* about pull vs. email. That's just the transport mechanism.
>> There may be a correlation, but it isn't important.
>
> Right, but Laszlo didn't ask "why pull requests", he asked
> "why signed pull requests", to which the answer is "because
> of the trust implied by the way our workflow uses pullreqs".

I believe he saw the discussion of *signed* pull requests and was
concerned that pull requests  were somehow dangerous in a way that
required extra validation before you could touch them. When in fact that's
not the case at all. The use of signatures permits personal trust to
eliminate the additional checking at the time you merge -- but that's a
completely orthogonal thing which *can* also apply with emails  (although
less easily as you observe).

The background is that they currently use a workshop which enforces
rebasing onto the latest master, thus leading to lost history and the
potential for commits which apparently *never* worked, in cases when we
*should* have a working commit and a subsequently broken merge. And I'm
trying to get them to fix that and use git properly, :)

-- 
dwmw2




reply via email to

[Prev in Thread] Current Thread [Next in Thread]