[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] why restrict pull reqs to signed tags?
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] why restrict pull reqs to signed tags? |
Date: |
Wed, 9 Mar 2016 13:13:34 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
On 03/09/16 12:35, Peter Maydell wrote:
> On 9 March 2016 at 17:20, Laszlo Ersek <address@hidden> 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
- [Qemu-devel] why restrict pull reqs to signed tags?, Laszlo Ersek, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, Paolo Bonzini, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, Peter Maydell, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?,
Laszlo Ersek <=
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, Paolo Bonzini, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, Laszlo Ersek, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, Paolo Bonzini, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, David Woodhouse, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, Ard Biesheuvel, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, Peter Maydell, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, Laszlo Ersek, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, David Woodhouse, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, Peter Maydell, 2016/03/09
- Re: [Qemu-devel] why restrict pull reqs to signed tags?, David Woodhouse, 2016/03/09