From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adczn-0005k2-5f for qemu-devel@nongnu.org; Wed, 09 Mar 2016 07:13:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adczi-0007bV-N0 for qemu-devel@nongnu.org; Wed, 09 Mar 2016 07:13:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adczi-0007bM-Gp for qemu-devel@nongnu.org; Wed, 09 Mar 2016 07:13:38 -0500 References: <56DFF8DA.2070408@redhat.com> From: Laszlo Ersek Message-ID: <56E0136E.8050709@redhat.com> Date: Wed, 9 Mar 2016 13:13:34 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] why restrict pull reqs to signed tags? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "Jordan Justen (Intel address)" , Paolo Bonzini , David Woodhouse , qemu devel list , Ard Biesheuvel On 03/09/16 12:35, Peter Maydell wrote: > On 9 March 2016 at 17:20, Laszlo Ersek 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