Re: got any tomatoes

[William Cohen <wcohen at redhat dot com>]

Chen, Brad wrote:
> Here is the draft test plan outline. Feedback would be
> much appreciated. Depending on feedback I'll look for 
> an appropriate home for this doc in the CVS repository.
>
> Key issues for everybody to think about:
> - How can we prioritize our testing efforts to get the
>   best possible results from the limited test resources
>   we will have at our disposal?
> - What existing projects have test infrastructure we'd
>   like to leverage? How can we motivate them to help us?
>
> Brad

Brad,

I don't have any tomatoes.

One of the things that might be an issue for this work is making sure 
that "things do not fall through the cracks." This is probably one of 
the reasons that the interpreters are popular; there is one gate that 
everything goes through. For system tap there are going to be some 
runtime checking in the support library code and other checked generated 
by the compiler. It would be possible for something to get overlooked. 
We are going to need to be very explicit where things are checked. The 
matrix in the safety section is helpful for this, but might not be 
detailed enough.

It might be wise to log/control the test from a separate machine. Make 
it easier to find out what crashed. Don't have to wait for the test 
machine to come back up before analyzing the data.

One of the carrots that might motivate kernel developers is to give them 
a better view of what is going on in the system during stress tests. Is 
the stress test exercising the sections of codes they expect? Then again 
maybe they have instrumented the code enough that they can see what is 
going on already.

What is the distinction between "3.6 Tapset infrastructure" and "3.8 
tapsets?" Talking about the special language constructs used to create 
the tapsets in 3.6. Also what happen to "3.7"?

-Will