Hi Nathan, On Wed, 2008-09-03 at 09:39 -0400, Nathan Straz wrote: > On Aug 31 00:24, Subrata Modak wrote: > > What about the GFS2 tests? You would know exactly whether they can be > > integrated inside LTP and to what proportion. > > We are in the process of open sourcing some of the tools we use in our > GFS/GFS2/Cluster test suites. I'm trying to get some useful man pages > done, then I will be making them available via Fedora People or
Good to know that. > Fedora Hosted. I will be sure to send the announcement to this list. > That will be wonderful. > Subrata, I was very impressed with the way you systematically asked for > tests from the major contributors to 2.6.26. I think that integrating > test cases which wouldn't otherwise have a home is a priority for LTP. Yes, you are correct. And not only that, integrating & automating all those tests which sit on developers desktop, is a big priority. And if developers are willing, then, request them to add some more tests for their domain. > > I don't think it is right to integrate every test suite into LTP. I'm > worried that merging actively maintained test suites will cause a fork > in the test suite and headaches for both LTP and upstream. I'm worried > that LTP will grow too large and these suites will get lost in the blob. > I'm worried that users of LTP will run the easy stuff, but not dig deep > enough to try running the embedded suites in new and interesting ways. > I don't want the only purpose of LTP to be to push a button and get a > pass or fail result. > > I don't think it's right to merge in the XFS or OCFS2 suites into LTP. > I don't want to merge the tools we've written into LTP either. They > will be available as separate packages and you're welcome to depend on > them, but I don't want to maintain the projects in two places. Yes, what i am looking at is: 1) Not maintain everything from LTP and in it´s original place as well. If even something is maintained in a different place, we should have the updated information and the suite available through LTP. Just to cite an example, the pounder21, open_posix, open_hpi, etc are maintained in different places, but the updated ones are also available through LTP. And the most recent example being Paul Moore´s permission to include AUDIT tests through LTP. So, AUDIT tests will have a different maintenance tree/project, but i will be tracking their releases. When i release LTP at month end, i can also include it´s release on the similar lines to open_hpi. The basic IDEA is to create a place where users can find most of Linux kernel testing parameters in a common place. So, even if the FS tests suite like the XFS, OCFS, GFS is maintained separately, i would like to provide integrated information about them to LTP community. If you feel that LTP will be growing much bigger, then we can accommodate them like the open_posix and open_hpi, instead of actually putting them under ltp/testcases/kernel/fs. Let me know your thoughts on this. Regards-- Subrata > > Nate ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
