Date: Wed, 9 Mar 2016 07:04:45 -0700
From: Jonathan Corbet <corbet@lwn.net>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>,
        Laszlo Ersek <lersek@redhat.com>
Subject: Re: [PATCH 2/7] Docs: Bring SubmittingPatches more into the git era
Message-ID: <20160309070445.37d301cd@lwn.net>
In-Reply-To: <1457516710.118898.188.camel@infradead.org>
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>
Organization: LWN.net
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2018
Lines: 48

On Wed, 09 Mar 2016 09:45:10 +0000
David Woodhouse <dwmw2@infradead.org> wrote:

> On Tue, 2014-12-23 at 09:32 -0700, Jonathan Corbet wrote:
> >  
> > -16) Sending "git pull" requests  (from Linus emails)
> > +16) Sending "git pull" requests
> > +-------------------------------
> > +
> > +If you have a series of patches, it may be most convenient to have the
> > +maintainer pull them directly into the subsystem repository with a
> > +"git pull" operation.  Note, however, that pulling patches from a developer
> > +requires a higher degree of trust than taking patches from a mailing list.  
> 
> This isn't really true, is it?
> 
> If I accept a stream of patches in email, or if I accept them in a pull
> request, I can — and should — still actually *look* at what's being
> applied before I push it back out again.

I think I put something in there somewhere about a one-year statute of
limitation on review comments :)

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.

jon