All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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: Tue, 06 Oct 2009 20:54:02 +0000	[thread overview]
Message-ID: <1254862442.4383.183.camel@mulgrave.site> (raw)
In-Reply-To: <alpine.LFD.2.01.0910060851590.3432@localhost.localdomain>

On Tue, 2009-10-06 at 08:58 -0700, Linus Torvalds wrote:
> 
> On Tue, 6 Oct 2009, James Bottomley wrote:
> >
> > This is mostly fixes.  However, it contains two new drivers: Brocade SAS
> > (bfa), the Bladengine2 iSCSI (be2iscsi) under the merge window exemption
> 
> Btw, I'm getting less excited about the merge window exemption.
> 
> It makes sense for consumer devices that people actually hit and that are 
> needed for bringup (ie they make a difference between a system that can be 
> installed and used, and one that cannot), but I'm not at all sure it makes 
> sense for things like this.
> 
> The _reason_ for the driver exemption was the fact that even a broken 
> driver is better than no driver at all for somebody who just can't get a 
> working system without it, but that argument really goes away when the 
> driver is so specialized that it's not about regular hardware any more.

OK, so I don't see a huge distinction here.  This is a driver for a
piece of enterprise HW that Linux previously didn't support.  To someone
cursing not being able to use there hardware, it's every bit as
important as the latest wireless driver.

> And the whole "driver exemption" seems to have become a by-word for "I can 
> ignore the merge window for 50% of my code". Which makes me very tired of 
> it if there aren't real advantages to real users.

While the exemption exists, I can certainly ignore the merge window for
new drivers, yes ... however, that's not 50% of the code submitted in
the merge window, and it's one time ... the same driver follows the
merge window for the next release.  I try to police this pretty rigidly
in SCSI ... as you do at the top.

In fact, for SCSI, these two drivers are the third and fourth merge
window exemptions in our year long history of allowing this.

> So I'm seriously considering a "the driver has to be mass market and also 
> actually matter to an install" rule for the exemption to be valid.

OK, so on the policy, let me argue against the above.  One of the things
we've been saying about linux is that we facilitate rapid adoption of
new hardware (and that we support more hardware than any other OS).  The
Merge window exemption was adopted at the kernel summit last year
specifically to speed our adoption of new hardware.  I think it's
valuable for this speed of adoption to be *all* hardware, not
specifically mass market laptop type stuff.

However, even if you want to change the definition, can we please not do
it retroactively?

Thanks,

James



  reply	other threads:[~2009-10-06 20:54 UTC|newest]

Thread overview: 46+ 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 [this message]
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
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-12 23:24                                     ` Greg KH
2009-10-13 18:08                                     ` Luis R. Rodriguez
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  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 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=1254862442.4383.183.camel@mulgrave.site \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.