Messages in this thread |  | | | From | Roland Dreier <> | | Subject | Re: [ANNOUNCE] Reiserfs/kill-bkl tree v2 | | Date | Sun, 02 Aug 2009 22:04:40 -0700 |
| |
> Well, dont waste too much time on it (beyond the due diligence > level) - Andi forgot that the right way to stress-test patches is to > get through the review process and then through the integration > trees which have far more test exposure than any single contributor > can test. > > Patch submitters cannot possibly test every crazy possibility that > is out there - nor should they: it just doesnt scale. What we expect > people to do is to write clean patches, to test the bits on their > own boxes and submit them to lkml and address specific review > feedback.
I respectfully disagree in this case. For patches that touch, say, something hardware dependent where the patch submitter doesn't have all the variations on the hardware, yes, I agree, scale the testing by running the code on many machines. But for the code in question, where some very fundamental and complex changes are being made to filesystem locking, I don't think that testing really scales -- after all, if there is some race then it's quite likely that testers will just see some rare filesystem corruption, which could easily waste weeks of debugging before the BKL/reiserfs patches were even implicated.
- R.
|  |