mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®