On 3/14/16 6:23 PM, Andreas Gruenbacher wrote: > On Mon, Mar 14, 2016 at 11:24 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: <snip> >> Most of this is as simple as copying the execution parts of your >> scripts to the xfstests test scripts, and the output parts of the >> test scripts into the test.out file. There's no new infrastructure >> needed for running tests, no separate richacl/ script directory, >> etc. > > I've said again and again that maintaining one set of richacl tests in > xfstests and another in the richacl package is going to really > painful, and that because of that, I'm trying to find a way of using > the same test scripts in both places. That message obviously didn't > get through at all though. That is just sad. Andreas, the issue as I see it is that xfstests is a large community project, with many users who have come to understand its implementation and its quirks^Wconventions. It is run and maintained by many people; over 150 authors have committed patches to the codebase. They understand how it all works together; it is a common language. The way you are proposing your richacl tests integration is unlike any other tests in the codebase; you have, to some degree, spliced your own test harness into xfstests, rather than following the advice of "When in Rome, do as the Romans do." This might make your life a little easier if you plan to maintain a separate repo of tests; in the meantime it makes life harder for the 150+ people who will be running and maintaining xfstests, not your test repo. The advantage of xfstests is that is is a common language, warts and all. It is run by developers and qa groups all over the world. There is a learning curve, but many people have learned it. Implementing your tests in this way adds a new and unique learning curve for all those people, and will make it less likely that others will share in the maintenance burden for these new tests. What I would suggest is that if you have tests which test only richacl userspace functionality, then perhaps you should keep them private to the richacl package. For tests which test kernel functionality, make them native to xfstests. This way you will get good coverage and maintenance help from all the people testing kernelspace with xfstests, and those hacking on richacls can run the tests local to it. This is more or less what e2fsprogs has done, and it seems to work out ok. -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
