On Thu, 2008-09-04 at 18:33 +0530, Subrata Modak wrote: > 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.
And, i have a typical example to give. The open_posix is no longer being maintained. But, people keep sending patches to open_posix though they never get accepted. Since, LTP has been including open_posix for long, we do not let these patches go away. We instead merge it in our open_posix subtree inside LTP. So, i would be happy if people would like to move their kernel testing stuff inside LTP. And in other case also, i would be happy to synchronize the LTP community with their developments as well. Regards-- Subrata > > 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
