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
