linux-kernel - Re: [GIT PULL] SCSI fixes for 2.6.32-rc3

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: <1255013810.4187.34.camel@mulgrave.site>
Date:	Thu, 08 Oct 2009 14:56:50 +0000
From:	James Bottomley <James.Bottomley@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] SCSI fixes for 2.6.32-rc3

On Thu, 2009-10-08 at 07:39 -0700, Linus Torvalds wrote:
> 
> On Thu, 8 Oct 2009, James Bottomley wrote:
> > 
> > So what do you want to do about this? 
> 
> I'm taking it (and the parisc one I was also unhappy with), but I'm a bit 
> grumpy as usual. The parisc pull came totally outside the merge window, 
> and the SCSI fix pull is technically perfectly fine, but what makes me 
> grumpy is that I get the strong feeling that people aren't even _trying_ 
> to hit the merge window with new drivers, because they decide that they 
> instead can just push them any time.

OK, so we still have a bit of a mismatch here.  I *do* tell people who
come to SCSI with new drivers that for the *first* submission they don't
need to worry about the merge window because of the new driver
exception.  This allows us to clean them up ready for going in without
the submitter feeling huge pressure to hit the merge window rather than
concentrating on code quality and what we need to make a technically
correct submission.

I think this is the correct thing to do for new drivers (which often
come with new writers) because training people to hit the merge window
is often long an painful (when I say not yet to their important driver
enhancements) ... starting people off with the carrot is better than the
stick.

> So I don't think I necessarily want to change the "new driver" policy per 
> se, but I want people to see the merge window as the _primary_ time you 
> get any new code in. The "yes, we'll take new drivers" thing should be the 
> exception rather than the rule. It doesn't seem to be an exception.

Like I said, this will be my fourth new driver under the exception in
the whole year it's been going.  On the other hand, I do have pm8001
still going ... it just got resubmitted after another round of fixes.
If it's ready for the next rc submissions round, it will be my fifth ...

James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/