On 6/13/05, Martin Husemann <martin@duskware.de> wrote:
> On Mon, Jun 13, 2005 at 01:13:26AM -0700, Chetan Patil wrote:
> > I was wondering who do I contact if I wish to work on the regression
> > system. I am interested to work on this and have regression testing
> > experience. Please let me know.
>=20
> There is a bit of information in the PR referenced in the project descrip=
tion
> (PR 23952). I'll hapilly answer any further questions that you have.
> Yes indeed. Silyl me, didn't see it.

> If you have proposals/things worth discussing, I guess this list is fine.
>=20
> Martin
>=20

Excerpts from PR23952
(1) There is no (optional?) automatic logging and summary at completition
     This is a SMOP, should be easy to fix.
--> Logging, Yes how about these fatures.
Two Main files. results.log and regress.log(contain all the info as
the test is executed). Test will have regress.log entry only if it
fails.

 By the way what is SMOP ?


(2) Ordinary User Vs Root user.
Run all the tests as ordinary user. Why ? Because 90% of the users who
will end up using the OS will run as ordinary user and not as root.
Some tests requiring Root user permissions should be elevated to root
and then executed. So we will essentially end up writing a utility to
give root permssions.

(3). I don't have much idea.

***************************************************************************=
********************
Suggestions:

Other thoughts:
1. Do we have hanging tests ? How about if they are run as a spawned
proces of say SpawnIT and set parametsr in SpawnIT to kill test after
certain time interval and other features as deemed necessary.
(Doable, I had done this for a class work with limited features.)

2.Are we tight on CPU cycles ?
How about running as more than one thread.
Single CPU --> Run test as 2 threads
Single CPU with Dual Core --> Run tests are 3 threads
More than 3 threads could be done but i suspect if hard disk can support it=
 ?
(Doable, but how ? hmm I have fair idea, but translating into working
code, I would need some help).

3. How about flagging tests with ids such that 64-bit(IA64, AMD64/EM64T)
tests are not run for x86. (I haven't paid close attention to
EM64T/AMD64 but I am assuming they are compatible).


4.Their should be one main regress script.(My ex Boss was of this
opinion that harness must not be modelled on the basis of OOAD).

Other suggested features for regress-main script are
1. Execute "n" number of tests( max or min)
2.save intermediate log files for failing tests. say
usr/local/kernel_4.c fails so create an intermediate log in the same
directory.
3.A way to resume test if it halts for some reason(core dump)
4. I could not do this. (Handle core dump. I purposely created a
situation for core dump and tried to handle it but I couldn't, script
would die. This will come very handy as it is not uncommon to see
core-dumps). OR maybe handle Kernel Panic(That would be an awesome
feature).
5.Pattern Matching to execute group of tests. Say the Developers moved
lot of code in some kernel libs and touched nothing else. Assuming we
have kernel tests in some folder say /usr/local/kernel, we can make
the devs execute only those tests and then checkin the fixes for
complete regression by lesser moretals like me, testers :)
(Doable, in limited capacity did for a class work).
6.Work on architecting and organizing the test suite such that we
should be able to use this test suite for further phases of testing,
say code coverage testing.
I would love to hear from you all. Maybe somethings you don't agree
with me but I would love to learn from my mistakes.

Thank you for the time.
Chetan