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

[Markus Armbruster]

David Woodhouse <address@hidden> writes:

> On Wed, 2016-03-09 at 15:41 +0100, Laszlo Ersek wrote:
>> According to your description, QEMU uses git improperly, so does
>> libvirt, and the KVM (kernel) queue too.
>
> Let's see...
>
> Imagine I'm working on a new feature, and I submit a carefully tested
> sequence of commits in a pull request.
>
> Someone *rebases* my work onto a different point in history, which
> introduces a bug.
>
> The record now shows that I submitted something *broken*. Like
> https://github.com/openssl/openssl/commit/963bb621 for example, which
> is utterly hosed and broke the build for everyone except me. 
>
> On that occasion, I was able to look back at what I *actually*
> submitted and point out that it wasn't my fault. But sometimes the
> breakage is more subtle. You end up looking back a few months later and
> trying to work out why an esoteric corner case is failing. You might
> ask me, and I'll say that I *distinctly* remember I thought about it,
> and that I could have sworn I *had* tested it.... 
>
> But again the record shows that what got merged has *never* worked.
> That's no longer just a problem of embarrassment for the submitter, by
> misrepresenting their work. That's now causing problems for the
> *project*. Because if history had been represented *correctly*, with a
> working commit and then a subsequent merge introducing the breakage,
> then that is a *whole* lot easier to figure out.
>
> Preserving accurate history is a large part of the reason we *have*
> version control systems. And yes, if any of those projects you list are
> deliberately throwing away history as a matter of course on non-trivial 
> submissions, then I would say that they are using the tools improperly.
>
> Of course, for simple patches it often makes no difference (well, apart
> from the OpenSSL example I gave above). And for larger submissions it
> doesn't *often* make a difference. But that's not the point. Sure, let
> people apply their *discretion* about rebasing stuff, if you really
> must — but a workflow which *enforces* a rebase, and *never* lets you
> pull a complex submission as it *actually* happened, is quite wrong.

Strawman alert: we don't *enforce* rebase.  We leave it to the
maintainer's discretion.

Nothing stops a maintainer (or a chain of them) from accepting pull
requests.  But for better or worse, most maintainers rebase most of the
time.  When they do, they add their S-o-B to every patch, which provides
a measure of accountability.

I acknowledge your points are worth considering, even though you
exaggerated for effect :)