At 01:16 PM 5/2/2001 -0600, Zak Greant wrote:
>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?
I don't think it's too realistic :)
I prefer having the php-general guys test it on their development machine's.
Andi
--
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]
