James Smart wrote:
Jeff Garzik wrote:
The lpfc update was probably the biggest thing, LOC-wise. And even
though that was mostly bug fixes -- and notably NOT 100% fixes -- it
is big enough to warrant integration testing and exposure prior to
mainline. Definitely merge-window-open material AFAICS.
FYI - it is integrated and tested prior to mainline, by Emulex (and who
else *really* tests it close to the degree we do ?). We do so, as a whole,
weeks ahead of the submit to the maintainer. Usually, there's only a couple
of small api changes that are picked up when we merge into the maintainers
pool. And most of these are caught by us prior anyway as we package the
patchsets and ensure the integration into the maintainers pool is smooth.
This is a highly common pattern, and unfortunately you get the highly
common Linux response:
In Linux we never ever assume a driver is working simply because the
hardware vendor tested it. A decade of real world experience PROVES
precisely the opposite -- getting code out into the world early and
often repeatedly turned up problems not seen in hardware vendor's testing.
Take a lesson from when I was on Linus's shit-list... twice: Twice,
Intel submitted an e1000 update after the merge window closed. Twice,
they claimed the driver passed their quite-exhaustive internal testing.
And twice, the most popular network driver broke for large masses of
users because I took a hardware vendor's word on testing rather than
rely on the testing PROVEN to flush out problems: public linux kernel
testing.
I'm not singling out Intel, there are plenty of other hardware vendors
that repeat the exact same pattern.
It's quite simply impossible for a hardware vendor to test all the weird
combinations in the field. Our test lab -- the Internet -- is the one
we trust.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
