Messages in this thread | | | Date | Wed, 27 Apr 2016 09:08:01 -0700 | Subject | Re: [GIT PULL] platform-drivers-x86 for 4.6-3 | From | Linus Torvalds <> |
| |
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
| |