From: Darren Hart <dvhart@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] platform-drivers-x86 for 4.6-3
Date: Wed, 27 Apr 2016 09:57:19 -0700 [thread overview]
Message-ID: <20160427165719.GA51171@f23x64.localdomain> (raw)
In-Reply-To: <CA+55aFwtirweH2pwo9T5=CtrHeEYtLyYtCZXmOOefo3e24tFdA@mail.gmail.com>
On Wed, Apr 27, 2016 at 09:08:01AM -0700, Linus Torvalds wrote:
> On Tue, Apr 26, 2016 at 10:02 PM, Darren Hart <dvhart@infradead.org> wrote:
> >
> > Found myself not wanting to send a one patch pull request, but not wanting to
> > wait until RC6 and possibly miss 4.6.
> >
> > Do you have a preference during the RC cycle in terms of balance between patch
> > count and frequency for a small subsystem like platform-driver-x86?
>
> Once a week like this is fine, even if it's just a single trivial
> one-liner change.
>
> I don't mind small pull requests at all, and I don't see "just one
> tiny commit" as being a bad thing. Quite the reverse. Those pull
> requests are easy, and it just makes me feel "good, that subsystem is
> calm and quiet, but not because the maintainer is not responding to
> people".
>
> In fact, getting small pull requests more often that once a week is
> also perfectly fine, although at that point there should be some
> _reason_ for it. But there are lots of valid reasons ("this is urgent
> because X", but also obviously things like "I maintain five different
> topic branches, this fourth pull request this week is for that other
> topic").
>
> The thing to avoid is a pattern of lots of pointless small pull
> requests, and in particular "oh, we found a problem in the last
> hurried pull requests, so here's _another_ half-arsed hurried pull
> request to fix that". At that point, I'd much rather just see the
> maintainer keep the commits in his tree for longer, and test them
> better, and just let them cook a bit more. So I _will_ complain if I
> notice that there's commits that are very recent and they look dodgy.
>
> But even there it's the _pattern_ that is annoying. If it happens once
> in a blue moon for a maintainer that otherwise has been dependable,
> that's fine. I can get really irritated if it's something that
> repeats.
Very helpful, thank you Linus. I believe I just inherited a TODO to find the
right spot in the documentation to record this.
--
Darren Hart
Intel Open Source Technology Center
next prev parent reply other threads:[~2016-04-27 16:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-27 4:58 Darren Hart
2016-04-27 5:02 ` Darren Hart
2016-04-27 16:08 ` Linus Torvalds
2016-04-27 16:57 ` Darren Hart [this message]
2016-04-28 4:25 ` RFC tips-for-maintainers.txt (was Re: [GIT PULL] platform-drivers-x86 for 4.6-3) Michael Ellerman
2016-04-28 17:43 ` Darren Hart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160427165719.GA51171@f23x64.localdomain \
--to=dvhart@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®