On Thu, Mar 11, 2010 at 7:24 AM, Rishikesh K Rajak <[email protected]> wrote: > On Thu, Mar 11, 2010 at 10:03:00AM -0300, Lucas Meneghel Rodrigues wrote: >> On Wed, 2010-03-10 at 21:11 -0800, Garrett Cooper wrote: >> > Hi all, >> > I just looked at the latest libevent, and I'm typically not one to >> > suggest this, but because libevent switched over to libtool in the 2.x >> > release (which is a pain in the ass to integrate), I think we just >> > drop the libevent testcase(s). I assume the maintainers run their >> > testcases on a subset of Unix machines, so it would just be an >> > annoying earmark that LTP has to maintain a dead // useless version of >> > libevent (eventually our version will go out of date and the code that >> > we have will bear little relevance and may be more buggy than the >> > latest version which should have appropriate tests and be executed and >> > triaged appropriately upstream). >> >> +1. Of course I am not in a position of saying something about what it >> should be done, but I totally agree that LTP should strive in keeping >> only well maintainted tests. It's harmful to keep unmantained code, it >> bitrots and tends to make everyone's life difficult.
bitrot is fine if something is functionally complete; it's of course not if it's incomplete or buggy. > Well said Lucas & garret. We need to really look for some outdated testcase > currently existing with LTP. I can look into it incrementally, but like garret > if someone come to know about outdated testcase with LTP or some tetssuit > which > need renewal, please let us know. We will work to renew them on high priority. > > Some of the testsuits i am looking are: > - cpu hot plug > - memory hotplug Removing testcases just because they're old isn't a good idea. We need to keep testcases that are still valid on older distros. I suggested removing libevent's code because they package their own set of testcases which are more appropriate to the code under test. Some other things that probably should be removed (and potentially augmented in the upstream projects are): Under testcases/: - ballista - I own developing the code now that I have more spare time (to some degree) and I was going to rewrite it from scratch because the current code is a mess, uses a lot of non-standard tools (c++ code, csh, perl, some bourne shell), isn't well designed, not BSD licensed, and the previous maintainers no longer maintain the code. - commands - there are much more extensive testcases and test suites with the implemented command suites themselves; so, why does LTP need its own set of tests which will have to fudge for each implementation when folks should be investing time in making sure that the issues in each of these test suites do conform to the specs (and potentially are POSIX compliant)? - libaio testscases (testcases out-of-sync with functionality) - open_hpi_testcases - why duplicate a stale copy of the test suite in the LTP repository, that doesn't necessarily match the copy of open_hpi on the box?? What if I don't need to test open_hpi? (majority of the folks on here who do embedded or simple validation work, don't have to. - pounder* - don't use it; it doesn't get compiled, etc Under tools/: top-LTP - doesn't compile; period -- hasn't been updated in years. Not even sure what in the heck it does. Thanks, -Garrett ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
