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

[Laszlo Ersek <lersek@redhat.com>]

On 03/09/16 12:35, Peter Maydell wrote:
> On 9 March 2016 at 17:20, Laszlo Ersek <lersek@redhat.com> wrote:
>> the question in the subject is not loaded, it is not trying to suggest
>> the opposite. It's a genuine question.
> 
> So, with an initial disclaimer that we have to some extent cargo-culted
> our process here from the kernel, my view is:
> 
>  * we only take pull requests from known submaintainers (ie I will
> not take a pull request from an arbitrary person)
>  * I don't do anything with pull requests beyond an automated build
> test and eyeball of the git log for any obvious howlers
>  * a pull request is therefore equivalent to being able to directly
> commit to master, and so it's worth using the signed-tag machinery
> to ensure that we only give those rights to the people (submaintainers)
> we think we've given them to

I understand, thank you. Especially your "directly commit to master"
analogy is good. Pulling replaces your detailed personal review with the
trusted identity of the pull requestor -- you trust that the commits on
the requestor's branch are already sufficiently reviewed.

http://thread.gmane.org/gmane.linux.kernel/1855303/focus=2172988

> Conversely, a random set of patches sent to the list is supposed
> to be reviewed and tested by the submaintainer who applies them to
> their tree -- that is the gateway at which review happens.

This was my understanding, yes.

David is proposing that direct pull requests be allowed on edk2-devel,
immediately from contributors, so that the contributor may ask for
his/her exact history to be preserved. I'm looking for examples: high
profile projects that have adopted such a workflow *all the while*
enforcing patch-wise reviews. Thus far I've come up empty.

I think the idea we have thus far is:

- submitter posts the patches
- patches are reviewed on the list
- submitter picks up the R-b, A-b, T-b labels
- when converged, submitter sends a pull request with the labels
applied, with the history he or she likes
- maintainer fetches the branch, verifies that the commits indeed match
the patches on list; also verifies that the labels have been correctly
picked up from the list
- maintainer merges the branch locally and pushes the merge commit (and
its deps) to upstream master

I feel a bit uncertain that we're trailblazing this workflow. It could
work I guess.

Thank you
Laszlo