Message-ID: <358a320b2b6e1ba6dab6f2800d3e4ee3.squirrel@twosheds.infradead.org>
In-Reply-To: <20160309070445.37d301cd@lwn.net>
References: <1419352327-4517-1-git-send-email-corbet@lwn.net>
    <1419352327-4517-3-git-send-email-corbet@lwn.net>
    <1457516710.118898.188.camel@infradead.org>
    <20160309070445.37d301cd@lwn.net>
Date: Wed, 9 Mar 2016 14:27:30 -0000
Subject: Re: [PATCH 2/7] Docs: Bring SubmittingPatches more into the git era
From: "David Woodhouse" <dwmw2@infradead.org>
To: "Jonathan Corbet" <corbet@lwn.net>
Cc: "David Woodhouse" <dwmw2@infradead.org>, linux-kernel@vger.kernel.org,
        "Randy Dunlap" <rdunlap@infradead.org>,
        "Laszlo Ersek" <lersek@redhat.com>
User-Agent: SquirrelMail/1.4.22-15.fc21
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
Importance: Normal
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1842
Lines: 41


> I wrote that text that way because certain high-profile maintainers have
> said exactly that sort of thing:
>
> 	You can send me patches, but for me to pull a git patch from you,
> 	I need to know that you know what you're doing, and I need to be
> 	able to trust things *without* then having to go and check every
> 	individual change by hand.
>
> 	-- Mr. T.  https://lwn.net/Articles/224135/
>
> ...and because, in truth, few maintainers do take pull requests.  There
> *is* some value in having the code out on the lists in the clear, it
> raises the chances of somebody *else* looking it over slightly.  There is
> a reason why review is done on the lists, not directly from repositories.
>
> Allowing the maintainer to attach tags certainly seems like another valid
> reason to defer setting patches into git-implemented stone.  But I don't
> see it as the only one.
>
> We could, I suppose, run a poll to ask maintainers why they are reluctant
> to take pull requests.  But the end result is kind of the same as far as
> readers of SubmittingPatches are concerned - they need to send their
> patches via email.

You are quite right that it has the same effect in practice, for Linux.
The problem was that your words were being taken out of context in a
situation where email review *was* always going to be required anyway, but
I'm trying to get them to allow pull requests instead of always losing
history by *forcing* a rebase onto the current HEAD.

Which is a model we use often too -- post for review and feedback, but
submit a pull request with the *actual* set of commits that were tested,
on the base they were developed against. Instead of submitting *only*
patches and running the risk that what gets committed to today's tree has
*never* actually worked correctly, when we look back at the inaccurate
history.


-- 
dwmw2