Re: Re: RE: [PHP-QA] 4.0.6

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