On Thu, 8 Oct 2009, James Bottomley wrote: > > OK, you're saying the merge window exemption should only apply to > drivers which meet our coding standards. Well, to me, it's not even "coding standards". It's more about "letting things slide so that users get their hands on things earlier, since it can't really regress". Coding standards are obviously a part of that, but I think the coding standard question should come into this mainly in the sense of "should it go through staging or not" kind of sense, not in the timing sense. The reason I object to this driver at this point is that I really think there's a _huge_ difference between some random average driver, and a 50 kloc monster driver that basically seems to implement its own protocol. Most random new drivers tend to be a few hundred lines of code, in some cases a few thousand. They don't generally bring in their own subsystem code, they often just hook into existing things like the libata layer or the network driver infrastructure etc. So most drivers are in a totally different class than the one I'm objecting to in the SCSI tree. And I also really do think there is a huge difference between some specialized high-end SCSI driver that is only relevant to enterprise people and some more average driver that is expected to perhaps exist in lots of consumer devices. How many people does it affect, and what's their ability to handle it? Another way of putting that "consumer" vs "enterprise" thing: how big is the _upside_ of merging the driver outside fo the merge window? Again, I simply think pure number of potential users matters for the "should we let it slide" question. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
