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] first round of SCSI updates for the merge window
Date: Sun, 24 Oct 2010 00:12:36 -0500	[thread overview]
Message-ID: <1287897156.3003.373.camel@mulgrave.site> (raw)
In-Reply-To: <AANLkTikZ-vePH+Wvf9S0-0PG1h+rRNByKEmXC2XENH1=@mail.gmail.com>

On Fri, 2010-10-22 at 17:48 -0700, Linus Torvalds wrote:
> On Fri, Oct 22, 2010 at 9:27 AM, James Bottomley
> <James.Bottomley@suse.de> wrote:
> > This represents the usual assortment of driver updates (bnx2i, zfcp,
> > qla, lpfc, ipr ..) plus several libfc and fcoe updates and a partial bfa
> > cleanup.
> 
> Why do you say "bfa cleanup"?
> 
> There's a _single_ commit that looks like this:
> 
>  220 files changed, 34823 insertions(+), 43478 deletions(-)
> 
> and which apparently rewrites the whole f*cking driver, with no
> explanations, no nothing. Why should anything like this be considered
> acceptable?
> 
> I'm going to pull it this once, because let's face it, nobody sane
> cares about that idiotic driver to begin with (and it does remove a
> lot more lines than it adds). But really, if I see something like that
> again, I will just tell you to go away and not send me crap like this
> again.
> 
> If it's that kind of crap, it should go into staging, or it shouldn't
> have been merged into the kernel in the first place.
> 
> Seriously. You need to start showing better taste. I realize that most
> of SCSI is crazy specialty hardware that is used by just a few people,
> but if you don't start pushing back on those vendors and make them do
> proper changes in small pieces and with actual commentary, then _I_ am
> going to push back at you. Hard. By simply not pulling crap.
> 
> This is not the first time I've been disgusted with the SCSI tree. And
> quite frankly, drivers like BFA are so totally irrelevant to anything,
> that I will have absolutely no problems with just saying "screw it, if
> they can't behave, they get removed from the kernel".
> 
> And don't blame it on bad vendors that won't do a good job. If they
> don't do a good job, then STOP TAKING THEIR CRAP. Make them understand
> that they need to work with the process, not do some kind of random
> "change everything, with no actual explanations". Blame me if you
> can't grow the balls to stand up to them. Tell them that I simply
> won't take it unless they clean up their act.
> 
> Because I really won't.

OK, so message received and understood.   The warning has already been
conveyed to the bfa maintainers (over a month ago). All of us appreciate
the one time grace.  I think this driver will finally start moving in
the right direction.

James

      parent reply	other threads:[~2010-10-24  5:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22 16:27 [GIT PULL] first round of SCSI updates for the merge window James Bottomley
2010-10-23  0:48 ` Linus Torvalds
2010-10-23 21:48   ` Roland Dreier
2010-10-23 22:13     ` Linus Torvalds
2010-10-24  4:32       ` Roland Dreier
2010-10-24  5:12   ` James Bottomley [this message]

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=1287897156.3003.373.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.