diff options
Diffstat (limited to 'community/gsoc/project_ideas/testsuites.mdwn')
| -rw-r--r-- | community/gsoc/project_ideas/testsuites.mdwn | 62 |
1 files changed, 0 insertions, 62 deletions
diff --git a/community/gsoc/project_ideas/testsuites.mdwn b/community/gsoc/project_ideas/testsuites.mdwn deleted file mode 100644 index 9ca6fe3e..00000000 --- a/community/gsoc/project_ideas/testsuites.mdwn +++ /dev/null @@ -1,62 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!meta title="Fix Compatibility Problems Exposed by Testsuites"]] - -A number of software packages come with extensive testsuites. -Some notable ones are [[open_issues/glibc]], gnulib, Perl, -Python, GNU Coreutils, and glib. -While these testsuites were written mostly to track regressions in the respective packages, -some of the tests fail on the Hurd in general. - -There is also the [[Open POSIX Testsuite|open_issues/open_posix_test_suite]] -which is more of a whole system interface testing suite. - -Then, there is the [[open_issues/File_System_Exerciser]] which we can use to -test our file system servers for conformity. - -While in some cases these might point to wrong usage of system interfaces, -most of the time such failures are actually caused by shortcomings in Hurd's implementation of these interfaces. -These shortcomings are often not obvious in normal use, -but can be directly or indirectly responsible for all kinds of failures. -The testsuites help in isolating such problems, -so they can be tracked down and fixed. - -This task thus consists in running some of the mentioned testsuites -(and/or any other ones that come to mind), -and looking into the causes of failures. -The goal is to analyze all failures in one or more of the listed testsuites, -to find out what shortcomings in the Hurd implementation cause them (if any), -and to fix at least some of these shortcomings. - -Note that this task somewhat overlaps with the [[Perl/Python task|perl_python]] listed above. -Here the focus however is not on improving the support for any particular program, -but on fixing general problems in the Hurd. - -This is a very flexible task: -while less experienced students should be able to tackle at least a few of the easier problems, -other issues will be challenging even for experienced hackers. -No specific previous knowledge is required for this task; -only fairly decent C programming skills. -While tracking down the various issues, -the student will be digging into the inner workings of the Hurd, -and thus gradually gaining the knowledge required for Hurd development in general. - -A complementary task is adding a proper [[open_issues/unit_testing]] framework -to the GNU Hurd's code base, and related packages. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: Take a stab at one of the testsuite failures, -and write a minimal testcase exposing the underlying problem. -Actually fixing it would be a bonus of course -- -but as it's hard to predict which issues will be easy and which will be tricky, -we will already be satisfied if the student makes a good effort. -(We hope to see some discussion of the problems in this case though :-) ) |