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

[Laszlo Ersek <lersek@redhat.com>]

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