lkml.org 
[lkml]   [2016]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [GIT PULL] platform-drivers-x86 for 4.6-3
From
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

\
 
 \ /
  Last update: 2016-04-27 18:21    [W:0.083 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site