Re: Testing (was Re: Patches for 0.8.8 to 0.8.11 (fwd) {cosmetic})

["Aram W. Mirzadeh" <aw...@qosina.com>]

At 10:43 AM 8/29/95 -0700, you wrote:
>
>I have put this on the members page as an additional field "OS Expertise" 
>for those who have indicated such.  
>
>I would like to propose, in the interests of more rigorous testing, that
>those who have volunteered to be experts for these platforms be responsible
>for, at a minimum:
>
>1) grabbing either the most recent build and applying the patches up for 
>vote to it or getting the experimental build with patches pre-applied

I think we should make it mandatory that all the patches be applied.  I know
I've skipped some because they didn't apply to my OS.  I've come to find that
is not the best way.  If a patch fails to patch cleanly, it should be fixed,
and 
then uploaded again to hypperreal.  There should also be a set of directories
to make this a little easier.   

Non-test-patches, test-patches that are going to be applied to the next release
and then new modifications.... none-bug patches, improvments.  This way we can
increase the gamma level, and not have to worry about the beta level of the 
release.  

>
>2) compiling the software and running it on a test port to make sure it 
>does basic startup and document serving

Let's pick a port, this way we can test each other's system without having
to try to find it?  I know this is a little too much to ask, but hey, what
the h....
not. 

>
>Going further I would like to come up with a test suite that includes 
>most of the major, and often error-prone, functions of the server.  Each 
>function should be tested on each platform to make sure something didn't 
>break on a particular OS because of a patch applied for another OS, etc.  
>Here's my attempt at suggesting what should be in this test suite:
>
>1) CGI scripts, initiated through both ScriptAlias and .cgi
>2) access control, implemented through both access.conf and .htaccess,
>   employing both host-based restrictions and password-based restrictions
>   and turning on and off various "options" parameters
>3) server-side includes, employing #include and #exec functions
>4) virtualhosts - at least one (since everyone can use 127.0.0.1)

Can you assign localhost as a virutual host?  I didn't know that.

>
>Any others?  Another part might be a variation of rob's monkey.c script, 
>where the testers can pummel the server with 20 basic requests/sec for an 
>hour and see how it holds up, since it looks like some bug reports have 
>involved the server dying after a little while.
>

<Aram>

BTW Brian, Location is: Long Island, NY.  (Edgewood, NY to be exact.)
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com