From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adfIW-0006Rq-3Q for qemu-devel@nongnu.org; Wed, 09 Mar 2016 09:41:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adfIR-0005Gd-3w for qemu-devel@nongnu.org; Wed, 09 Mar 2016 09:41:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adfIQ-0005GY-UX for qemu-devel@nongnu.org; Wed, 09 Mar 2016 09:41:07 -0500 References: <56DFF8DA.2070408@redhat.com> <56E0136E.8050709@redhat.com> <1457526892.118898.239.camel@infradead.org> <1457528972.118898.257.camel@infradead.org> <2e237edf67147cad0710accce5808f35.squirrel@twosheds.infradead.org> From: Laszlo Ersek Message-ID: <56E03600.2040602@redhat.com> Date: Wed, 9 Mar 2016 15:41:04 +0100 MIME-Version: 1.0 In-Reply-To: <2e237edf67147cad0710accce5808f35.squirrel@twosheds.infradead.org> 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: David Woodhouse , Peter Maydell Cc: "Jordan Justen (Intel address)" , Paolo Bonzini , qemu devel list , Ard Biesheuvel On 03/09/16 15:13, David Woodhouse wrote: > The background is that they currently use a workshop which enforces > rebasing onto the latest master, thus leading to lost history This is exactly what the QEMU development model enforces, as I've repeated many times. Maintainers who review and pick up your QEMU patches will freely rebase them, reorder them against other contributors' series they queue until their next pull, and resolve rebase conflicts without asking you if they can. What I may have forgotten to say (but have been reminded of) is that maintainers are personally responsible for *testing* such rebases before they send a PULL with them. Nonetheless, I don't think such testing would make much difference for you, because (a) the history would be changed anyway, which you can't accept, and (b) IIRC I volunteered to test your (great) OpenSSL work in practice even before you did, even without being a CryptoPkg co-maintainer, but that still doesn't seem to give you enough confidence in our workflow. My point is that the workflow we currently use in edk2 is not *inherently* broken. Many other projects, like QEMU, use it. > 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, :) According to your description, QEMU uses git improperly, so does libvirt, and the KVM (kernel) queue too. Anyway, I think we're running in circles. I won't try to block this endeavor in edk2. If (a) merges become generally accepted by the other package maintainers in edk2, and (b) a contributor asks me personally that his branch be pulled rather than rebased, I'll do my best to conform, while ensuring correctness & security. Until (a&&b), I as an edk2 co-maintainer will definitely follow the current rules. I apologize again for the noise on qemu-devel; I'm out. Laszlo