On Thu, Nov 03, 2011 at 03:04:17PM +0400, Dmitry Monakhov wrote: > On Thu, 3 Nov 2011 06:54:16 -0400, Theodore Tso <tytso@xxxxxxx> wrote: > > > > On Nov 2, 2011, at 3:55 PM, Christoph Hellwig wrote: > > > > > Alex, Eric, Dave - should we add new tests with the new operations > > > Dmitry added, or is adding new ops to the existing tests fine? > > > > One argument for adding new ops to existing tests is that it makes > > the run time of the entire test suite take longer. A QA pass is > > already taking quite a while, and it would be nice if we could > > keep xfstests as efficient as possible in terms of the maximum > > testing coverage per time spent running the test suite…. > > Yes, but regression test with explicit seed option should be > preserved. Number of such test is not too big, so it is reasonable to > hardcode set of operations in such tests and let all others use new features. That's not what I was talking about. Of course there should be a way to run a regression test with an explicit seed option (although in general I think a specific test in xfstests should by default use a random seed, and have a way to easily specify an explicit seed without having to reverse engineer the test and running fsstress manually). What I was talking about was the fact we already have several (half a dozen or so, if memory serves correctly) xfstests that use fsstress with a different set of fsstress options. In some cases it makes to add a new numbered xfstest subtest, but I'd rather not find that we've doubled the number of tests using fsstress in the future, and with it, doubled the run-time of the auto or quick xfstests group.... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
