How exactly would you define success/failure of the RC?...
I mean, if it crashes, you can probably catch that, but what if the output
is just incorrect?
You're back to the problem of only a pre-determined (and very limited)
validation suite can really use this, I think...
Or am I just being obtuse and difficult?
What might be more realistic would be to "fork" the request to an invisible
(to the end user) testing machine and real machine.
Then, the outputs of the two can be compared, and an error report of some
kind generated for any differences.
Ideally, the production output would be sent on its way without any "delay"
waiting for the testing machine to
respond/fail/explode-in-a-burst-of-flames.
There is some overhead, of course, but I *think* this is a more feasible
design, possibly even "doable"...
--
WARNING [EMAIL PROTECTED] address is not working -- Use [EMAIL PROTECTED]
Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm
----- Original Message -----
From: Zak Greant <[EMAIL PROTECTED]>
To: James Moore <[EMAIL PROTECTED]>; Andi Gutmans <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, May 02, 2001 2:16 PM
Subject: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
> Andi wrote:
> [snip]
> > That was really a big disappointment as people did such a good job on
the
> > release cycle IMO.
> > No doubt it shouldn't have slipped in.
> > And if it doesn't get fixed soon we should revert to the old version of
> the
> > COM module.
>
> How much testing is the QA team actually doing? I would suspect that
> the
> majority of the QA team follows the same slack process that I follow.
>
> 1.) build the latest release
> 2.) make test
> 3.) look at phpinfo()
> 4.) see what happens to a few scripts
>
> Am I right? :)
>
> We should be testing the RC's against large bodies of working
> code that real users are using. This is tough to do - no one wants to
> break a working site.
>
> How difficult (and useful) would it be for us to have a system like
> the one describe below.
>
> The standard PHP SAPIs and CGI executable are replaced by shell that
> maintains environment data and passes it to an RC. The RC attempts
> to handle the request. If it fails, the shell passes the same request
> is passed to a stable version of PHP, and the failure is logged,
> along with the environment data, etc...
>
> The user request may be slowed, but is still served. The shell
> could include threshold settings so that we stop passing requests
> known to break the RC after a certain number of requests...
>
> By co-operating with various site owners, we could get the RCs into
> environments where they server millions of hits in a day in a broad
> range of situations.
>
> Anyone think that this blueskying is useful or possible?
>
> --zak
>
>
> --
> PHP Quality Assurance Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
