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

[James Bottomley]

On Mon, 2009-10-12 at 10:24 -0700, Linus Torvalds wrote: 
> 
> On Mon, 12 Oct 2009, James Bottomley wrote:
> > > 
> > > I think you are interpreting what should go into drivers/staging/ _very_ 
> > > narrowly.
> > 
> > As it is my right to do.
> 
> Umm, James, it cuts both ways.
> 
> Others can assert their interpretation, and quite frankly, yours is the 
> odd one out. Everybody else agrees oevrwhelmingly that "staging" is about 
> ugly and not-up-to-snuff drivers.

I haven't actually ever said otherwise.  I have asserted that the bfa
driver, while large, isn't out of the ball park for a FC driver, that it
does provide all the correct user visible FC ABI pieces but that it does
have minor anomalies, primarily in bfa/include, that need cleaning up,
plus it needs to interface to libfc at some future point.  I have also
asserted that drivers/scsi is the best place to address the remaining
issues.

> So you can talk about your 'right' to interpret things all you want, but 
> what's the point? If others haev the same right (which presumably even you 
> agree they do), then if people think a driver is ugly and needs to be in 
> staging, what makes _your_ right so special?

It's a judgement call whether a driver goes through staging or not.  I'm
happy to hear other opinions about this driver, but I'd like them to be
from reading the code, not generalities.  I've stated my specific
reasons why this driver isn't a good candidate for staging.

> As mentioned earlier, I don't personally care about this driver, but I do 
> care about your behavior. You can't just ignore other people if they say 
> that a driver is too damn ugly.

But no-one's actually said that.  The whole discussion was theoretical
rather than based on this driver.  My position on the generalities is
that ABI issues head a driver automatically for staging.  For non user
visible code based issues, it's a maintainer judgement call where the
cleanup is best done, which in turn depends on what the actual issues
are.  For this specific driver, I've given reasons several times why the
changes are best made in drivers/scsi.

James


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