From: Theodore Tso <tytso@mit.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: James Bottomley <James.Bottomley@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] SCSI fixes for 2.6.32-rc3
Date: Thu, 8 Oct 2009 17:07:37 -0400 [thread overview]
Message-ID: <20091008210737.GD29181@mit.edu> (raw)
In-Reply-To: <alpine.LFD.2.01.0910081255510.3432@localhost.localdomain>
On Thu, Oct 08, 2009 at 01:00:58PM -0700, Linus Torvalds wrote:
>
> It really boils down to the fact that I'm perfectly happy to let new
> drivers slip in after the merge window in order to help end users. But
> really - there has to be a limit to it. Not just anything.
>
> It has to help end users, and dammit, you have to admit that 50 kloc is
> damn well not just "another random driver".
So would it be acceptable to merge the 50 kloc of crap _during_ the
merge window? Crap is crap, no matter when it is merged. In this
particular case, the crap is its own subsystem, and wouldn't interfere
with the rest of the kernel tree. So it's no more risky to merge it
outside of merge window; so the decision about whether merge 50 kloc
of crap shouldn't be impacted about whether we are in our out of the
merge window.
Arguably, the question is whether it's better for the end users to
merge this at _any_ time, or whether we force the manufacturer to drop
it into the staging tree provisionally until it can be cleaned up.
- Ted
next prev parent reply other threads:[~2009-10-08 21:08 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-06 15:46 [GIT PULL] SCSI fixes for 2.6.32-rc3 James Bottomley
2009-10-06 15:58 ` Linus Torvalds
2009-10-06 20:54 ` James Bottomley
2009-10-06 20:56 ` Randy Dunlap
2009-10-08 14:33 ` James Bottomley
2009-10-08 14:39 ` Linus Torvalds
2009-10-08 14:54 ` Linus Torvalds
2009-10-08 19:48 ` James Bottomley
2009-10-08 19:55 ` Linus Torvalds
2009-10-08 20:00 ` Linus Torvalds
2009-10-08 21:07 ` Theodore Tso [this message]
2009-10-08 21:13 ` Linus Torvalds
2009-10-09 9:15 ` Ingo Molnar
2009-10-09 13:10 ` Daniel Walker
2009-10-09 14:08 ` James Bottomley
2009-10-09 19:25 ` Greg KH
2009-10-12 13:06 ` Ingo Molnar
2009-10-12 14:19 ` James Bottomley
2009-10-12 14:54 ` Ingo Molnar
2009-10-12 15:09 ` Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3) Greg KH
2009-10-12 15:42 ` Ingo Molnar
2009-10-12 23:24 ` Greg KH
2009-10-13 18:08 ` Luis R. Rodriguez
2009-10-14 4:45 ` Greg KH
2009-10-14 5:19 ` Joe Perches
2009-10-14 6:33 ` Ingo Molnar
2009-10-14 14:13 ` James Smart
2009-10-14 17:52 ` Stefan Richter
2009-10-14 18:36 ` Ingo Molnar
2009-10-14 19:00 ` Stefan Richter
2009-10-15 6:03 ` Ingo Molnar
2009-10-14 19:11 ` Greg KH
2009-10-12 15:43 ` James Bottomley
2009-10-12 23:26 ` Greg KH
2009-10-12 15:25 ` [GIT PULL] SCSI fixes for 2.6.32-rc3 James Bottomley
2009-10-12 17:24 ` Linus Torvalds
2009-10-13 14:29 ` James Bottomley
2009-10-12 14:25 ` Greg KH
2009-10-08 20:04 ` James Bottomley
2009-10-08 20:25 ` Linus Torvalds
2009-10-10 14:37 ` James Bottomley
2009-10-08 14:56 ` James Bottomley
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=20091008210737.GD29181@mit.edu \
--to=tytso@mit.edu \
--cc=James.Bottomley@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).