Messages in this thread | | | Date | Tue, 07 Aug 2007 12:34:54 -0400 | From | Jeff Garzik <> | Subject | Re: [GIT PATCH] scsi bug fixes for 2.6.23-rc2 |
| |
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-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/
| |