lkml.org 
[lkml]   [2009]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
FromRoland Dreier <>
SubjectRe: [ANNOUNCE] Reiserfs/kill-bkl tree v2
DateSun, 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.


\
 
 \ /
  Last update: 2009-08-03 07:07    [from the cache]
©2003-2010