All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Darren Hart <dvhart@infradead.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:08:01 -0700	[thread overview]
Message-ID: <CA+55aFwtirweH2pwo9T5=CtrHeEYtLyYtCZXmOOefo3e24tFdA@mail.gmail.com> (raw)
In-Reply-To: <20160427050213.GA9622@f23x64.localdomain>

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.

                  Linus

  reply	other threads:[~2016-04-27 16:08 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 [this message]
2016-04-27 16:57     ` Darren Hart
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='CA+55aFwtirweH2pwo9T5=CtrHeEYtLyYtCZXmOOefo3e24tFdA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=dvhart@infradead.org \
    --cc=linux-kernel@vger.kernel.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.