> Proposal 1: > > Create a new option for the daemons to specify that it is running as > test mode, then we can skip fsync calls used for data durability. Alternatively, run tests with the relevant directories (bricks and /var/lib stuff) in ramdisks. No code change needed, but some tests might need to be resized to read/write less data (probably a good idea anyway). FWIW, I already do this for tests I run myself. > Proposal 2: > > Use ip address instead of host name, because it takes some good amount > of time to resolve from host name, and even some times causes spurious > failure. If resolution is taking a long time, that's probably fixable in the test machine configuration. Reading a few lines from /etc/hosts should take only a trivial amount of time. > Proposal 3: > Each component has a lot of .t files and there is redundancy in tests, > We can do a rework to reduce the .t files and make less number of tests > that covers unit testing for a component , and run regression runs once > in a day (nightly) . I wouldn't favor a general reduction of tests so much as a reduction (and reordering) of which ones get run for a particular change. For example, if a patch is to AFR then it's most likely to fail in an AFR test so we should run those first. On the flip side, it's unlikely to fail in an SSL test, so maybe we don't need to run those at all (except nightly). If we had a "map" of which tests are most relevant to which pieces of code, we could automate the process of deciding which tests to run first, which to run second, and which to skip altogether, all on a per-patch basis. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
