All of lore.kernel.org
 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 [GIT PULL] platform-drivers-x86 for 4.6-3 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.