Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934076AbZJITaK (ORCPT ); Fri, 9 Oct 2009 15:30:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761342AbZJITaJ (ORCPT ); Fri, 9 Oct 2009 15:30:09 -0400 Received: from cantor.suse.de ([195.135.220.2]:52015 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761330AbZJITaI (ORCPT ); Fri, 9 Oct 2009 15:30:08 -0400 Date: Fri, 9 Oct 2009 12:25:33 -0700 From: Greg KH To: James Bottomley Cc: Ingo Molnar , Linus Torvalds , Theodore Tso , Andrew Morton , linux-scsi , linux-kernel , Jing Huang Subject: Re: [GIT PULL] SCSI fixes for 2.6.32-rc3 Message-ID: <20091009192533.GA32084@suse.de> References: <1255012399.4187.24.camel@mulgrave.site> <1255031298.4187.260.camel@mulgrave.site> <20091008210737.GD29181@mit.edu> <20091009091538.GA4154@elte.hu> <1255097287.2934.21.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1255097287.2934.21.camel@localhost.localdomain> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2547 Lines: 56 On Fri, Oct 09, 2009 at 09:08:07AM -0500, James Bottomley wrote: > On Fri, 2009-10-09 at 11:15 +0200, Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > > > On Thu, 8 Oct 2009, Theodore Tso wrote: > > > > > > > > So would it be acceptable to merge the 50 kloc of crap _during_ the > > > > merge window? > > > > > > Yes. I actually looked at the driver (since I had pulled it - I've > > > unpulled it but am still mulling it over), and while I think it looked > > > huge and overly complex, it by no means gave me the kinds of vibes I > > > get from some "obviously-ported-from-windows-with-no-clue" drivers. > > > > > > So at least from my quick look I didn't get the feeling that the > > > driver was "evil". For me, it's a timing issue. I hate getting big > > > pull requests after -rc1 is out, and I really don't like the feeling > > > that people are just ignoring the merge window. > > > > > > That said, if somebody wants to look more closely at the driver, and > > > then wants to convince people that it should have gone through > > > "staging", feel free. But that's not what I've personally been arguing > > > about. > > > > Greg, what's your take on the quality of this new driver? Do you have > > some time to do a review of this with drivers/staging/ versus drivers/ > > glasses on? The Git URI is at: > > To me, the matter of staging versus actual tree isn't a quality issue > (otherwise we'd be shifting ~75% of SCSI drivers to staging, depending > on whose view of "quality" was being used). Great, I'll be glad to take them :) > It's an ABI issue. If we would have to change the user visible ABI > while the driver was being cleaned up, I'd want it in staging to warn > users to expect these problems. Although we couldn't clean up > everything, I did make sure this driver plugs correctly into the > standard linux FC ABI before putting it in the SCSI tree, so there are > no ABI changes anticipated even though there will likely be a lot of > code changes. Therefore, the correct clean up path for this one is > through the SCSI tree. Ok, that's your call as the scsi maintainer. If you need anything to go into staging as an incentive to get the code cleaned up, or if not, dropped, just send it to me. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/