Stress-Testing Project :
------------------------

The aim is to create a team of individuals, not necessarily committers,
that will do stress-testing by using various automated test suites,  in
order to improve the quality of FreeBSD releases by catching more bugs,
and by producing all the informationg necessary for the developers to
fix them.

For this to happen, we need to provide the interested people with an
infrastructure that will allow this project to become a reality.  That
means a number of things :

- A place where to put webpages hosted on the freebsd.org cluster.  The
  wikitest (http://wikitest.FreeBSD.org/) is probably a good place to
  start.  If deemed desirable, it could later be put on the main FreeBSD
  website under projects, and the members of the team will need a doc
  commit it to modify it.

- A mailing list to talk about everything related to this project.

- Hardware.  Lots of it.  They'll need it to run the suites :-).

- Get people into the loop.  Many people have already started similar
  things by their own, and will probably be interestd by it.  For instance,
  we need to talk to Peter Holm that is doing a lot of stress-testing by
  himself.  Kris Kennaway, by managing the cluster for packages building,
  is very active in this field too, as we all know :-). Bjoern Zeeb has
  been maintaining a webpage of known LORs, so he may want to join this
  effort as well.  Dag-Erling Smorgrav, the author of the tinderbox
  scripts seems to be interested in automated testing.  I'm probably
  missing people here...

- It would be nice if the FreeBSD project could give some kind of "reward"
  to the active members of the team, in order to help maintain motivation.

- The core team needs to make a formal announcement in some public mailing
  lists to attract more people in joining the effort.

Many people can join the effort since there are a lot of things to do :

- Writing new stress-test suites and regression test suites and improving
  the existing ones.  There are a lot of different things suites to write,
  to stress-test every significant part of the system, write conformance
  tests for POSIX standards, etc...

- Improve the existing debugging tool and problem reporting tools.  It
  would be desirable to have the system dump more debugging information,
  ddb output, etc along with the core.  That would make debugging stuff
  easier since we wouldn't have to round trip saying "panic it again, then
  trace the following threasd", etc.  It would also be nice to have
  send-pr(1) able to generate most if not all of a problem report by
  looking at the core itself, getting a trace etc..