linux-kernel - Re: [GIT PULL] platform-drivers-x86 for 4.6-3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160427165719.GA51171@f23x64.localdomain>
Date:	Wed, 27 Apr 2016 09:57:19 -0700
From:	Darren Hart <dvhart@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] platform-drivers-x86 for 4.6-3

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@...radead.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