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 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]
