Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!
At 19:28 21-6-2001 +0200, Sascha Schumann wrote: On Thu, 21 Jun 2001, Wico de Leeuw wrote: Hiya i get this error when doing make under apache 1.3.20 A more interesting info would be the output of gcc -v. this error is for php-4.0.5 and php-4.0.6 for apache 1.3.17 and 1.3.20 php 4.0.4pl compiles fine with 1.3.14 and 1.3.17 Greetz, Wico [root@linux php-4.0.5]# gcc -v Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/pgcc-2.95.2.1/specs gcc version pgcc-2.95.2.1 20001224 (release) - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!
[root@linux php-4.0.5]# gcc -v Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/pgcc-2.95.2.1/specs gcc version pgcc-2.95.2.1 20001224 (release) `pgcc´ is an experimental compiler. Such issues are to be expected with this kind of software. For a production system, I'd recommened a stable compiler like GCC 2.95.3 which has no problems building the PHP 4 source tree (ditto for vanilla 2.95.2.1). - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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]
[PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!
4.0.6 built ok on Suse 7.1. Tested with my code (MySQL stuff mainly) and PhpMyAdmin. No problems found. Cheers -- Phil Driscoll -- 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]
[PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!
At 10:04 21/06/2001 +0300, Andi Gutmans wrote: http://www.php.net/~andi/php-4.0.6.tar.gz *** Configured, compiled and ran under ten minutes using the instructions i posted yesterday for RC4. Yeahay ! Welcome to the world new release ;-) hellekin -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!
Hiya i get this error when doing make under apache 1.3.20 gcc -c -I../../os/unix -I../../include -DLINUX=22 -I/home/src/wico/php-4.0.6 -I/home/src/wico/php-4.0.6/main -I/home/src/wico/php-4.0.6/main -I/home/src/wico/php-4.0.6/Zend -I/home/src/wico/php-4.0.6/Zend -I/home/src/wico/php-4.0.6/TSRM -I/home/src/wico/php-4.0.6/TSRM -I/home/src/wico/php-4.0.6 -I/home/src/wico/php-4.0.6 -I/home/src/wico/php-4.0.6/main -I/home/src/wico/php-4.0.6/main -I/home/src/wico/php-4.0.6/Zend -I/home/src/wico/php-4.0.6/Zend -I/home/src/wico/php-4.0.6/TSRM -I/home/src/wico/php-4.0.6/TSRM -I/home/src/wico/php-4.0.6 -DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED -Os -O6 -march=pentium `../../apaci` -DAPACHE xmltok.c In file included from xmltok.c:260: xmltok_impl.c: In function `normal_getAtts': xmltok_impl.c:1478: Internal compiler error in `do_spl', at loop.c:12473 At 13:03 21-6-2001 +0100, Phil Driscoll wrote: 4.0.6 built ok on Suse 7.1. Tested with my code (MySQL stuff mainly) and PhpMyAdmin. No problems found. Cheers -- Phil Driscoll -- 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] -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!
On Thu, 21 Jun 2001, Wico de Leeuw wrote: Hiya i get this error when doing make under apache 1.3.20 A more interesting info would be the output of gcc -v. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
The question is, if you think people will actually download the RC in order to test it (as opposed to using it) - why won't they join the QA team? Because they have enough time to make sure their software still works with the RC, but not enough time to wade through all the QA emails. :-) Most likely, though, the cost/benefit ratio of mass distribution of the RCs is borderline -- And throwing a few more resources at the QA team (eg Win binaries) will be far more effective. There will *always* be some bugs that only get found by mass testing. The COM bug should have been caught by a QA team member, and you've identified why not. :-) :-) :-) Suggested Compromise Ultimatum: Windows binaries and Zend test machine before 4.0.6RC1, or post RC announcement to the masses. This should goad us (okay, you) into having the process in place or suffering the consequences :-) :-) :-) -- 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 -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
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]
[PHP-DEV] Re: [PHP-QA] 4.0.6
Andi Gutmans wrote: I think we should make a list of known 4.0.5 bugs which need to be fixed for 4.0.6 and once we fix them branch 4.0.6. I think there have been enough changes to warrant a 4.0.6 release soon. and i would suggest to announce the RCs not only here but on php.net and freshmeat.net as well -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 15:18 2/5/2001, Hartmut Holzgraefe wrote: Andi Gutmans wrote: I think we should make a list of known 4.0.5 bugs which need to be fixed for 4.0.6 and once we fix them branch 4.0.6. I think there have been enough changes to warrant a 4.0.6 release soon. and i would suggest to announce the RCs not only here but on php.net and freshmeat.net as well I don't think that's a good idea, because then people will treat them as releases. I think that the way things are currently, plus the natural growth of the QA team, are the right way to go. Zeev -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 04:02 PM 5/2/2001 +0300, Zeev Suraski wrote: At 15:18 2/5/2001, Hartmut Holzgraefe wrote: Andi Gutmans wrote: I think we should make a list of known 4.0.5 bugs which need to be fixed for 4.0.6 and once we fix them branch 4.0.6. I think there have been enough changes to warrant a 4.0.6 release soon. and i would suggest to announce the RCs not only here but on php.net and freshmeat.net as well I don't think that's a good idea, because then people will treat them as releases. I think that the way things are currently, plus the natural growth of the QA team, are the right way to go. I disagree. We are not getting enough testing of our RCs. I think if we announce an RC and we tell people they are just helping us test the pre-release it's OK. It's not as if they can't grab a snapshot. 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]
[PHP-DEV] Re: [PHP-QA] 4.0.6
At 02:18 PM 5/2/2001 +0200, Hartmut Holzgraefe wrote: Andi Gutmans wrote: I think we should make a list of known 4.0.5 bugs which need to be fixed for 4.0.6 and once we fix them branch 4.0.6. I think there have been enough changes to warrant a 4.0.6 release soon. and i would suggest to announce the RCs not only here but on php.net and freshmeat.net as well Yes we should probably get more people testing the RCs. Maybe the regular PHP mailing list is enough. 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 16:02 2/5/2001, Andi Gutmans wrote:
I disagree. We are not getting enough testing of our RCs.
I think if we announce an RC and we tell people they are just helping us
test the pre-release it's OK.
It's not as if they can't grab a snapshot.
People usually tend to deal with pre-release or release candidate as if
they're releases. It's not that RC's are necessary significantly less
stable than releases, but I don't think that announcing them on such wide
forums would give our QA efforts anything. It's pretty much the same as
saying we announce 4.0.{x} as an RC for 4.0.{x+1}, because 4.0.{x} bugs
will start flowing as soon as it's out.
What I'm trying to say is that if we make that jump from a QA team to the
entire world, then essentially, we go a step backwards. I think that the
way things are today is good, and most of the bugs which aren't found can
only be found in wide scale testing, but I don't think that announcing RCs
in prominent places is the way to go.
Perhaps we should announce the QA team again, so that people who would join
but don't know about it would get a chance.
Zeev
--
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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 04:15 PM 5/2/2001 +0300, Zeev Suraski wrote:
At 16:02 2/5/2001, Andi Gutmans wrote:
I disagree. We are not getting enough testing of our RCs.
I think if we announce an RC and we tell people they are just helping us
test the pre-release it's OK.
It's not as if they can't grab a snapshot.
People usually tend to deal with pre-release or release candidate as if
they're releases. It's not that RC's are necessary significantly less
stable than releases, but I don't think that announcing them on such wide
forums would give our QA efforts anything. It's pretty much the same as
saying we announce 4.0.{x} as an RC for 4.0.{x+1}, because 4.0.{x} bugs
will start flowing as soon as it's out.
What I'm trying to say is that if we make that jump from a QA team to the
entire world, then essentially, we go a step backwards. I think that the
way things are today is good, and most of the bugs which aren't found can
only be found in wide scale testing, but I don't think that announcing RCs
in prominent places is the way to go.
Perhaps we should announce the QA team again, so that people who would
join but don't know about it would get a chance.
I don't think that the PHP mailing list is the whole world. It's a fairly
large amount of people but a relatively small percent of the amount of
downloaders (10% IMO).
I think that the amount of QA people (even if the amount doubles) is enough
to find those little bugs that crept in.
And many bugs can only be found by trying to actually run the RC for a few
days on a development machine. I don't know how many QA guys actually do that.
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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. Zeev At 16:08 2/5/2001, Hartmut Holzgraefe wrote: Zeev Suraski wrote: I don't think that's a good idea, because then people will treat them as releases. thats just a matter of labeling and announcement message I think that the way things are currently, plus the natural growth of the QA team, are the right way to go. IMHO the current peak in new bug reports tells a different story -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
What I'm trying to say is that if we make that jump from a QA team to the entire world, then essentially, we go a step backwards. I think that the way things are today is good, and most of the bugs which aren't found can only be found in wide scale testing, but I don't think that announcing RCs in prominent places is the way to go. Perhaps we should announce the QA team again, so that people who would join but don't know about it would get a chance. I don't see how announcing RCs which are explicitly marked as such in a larger forum can hurt PHP or the release process. Could you elaborate? - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. The COM problem would have been found IMO if we had released a bigger RC. 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On Wed, 2 May 2001, Andi Gutmans wrote: The COM problem would have been found IMO if we had released a bigger RC. I think the COM problem would have been found if somebody ran the test suite immediately before releasing 4.0.5 final. I think modifying the RC process to ensure that the last thing we do before releasing is to make sure the release passes the validation suite is a simpler step than opening the QA process to thousands of less qualified testers. I know the QAT does its best to build and validate the RCs on as many platforms and configurations as possible. But, always adding in new features, to go along with bug fixes, makes it harder to gather all the testers together to review each RC. If we had less RCs or the RCs modified fewer files, it'd be easier to ensure like mistakes like COM don't slip through the cracks. We always have minor buglets in the RCs. It's much easier for the QAT to locate them internally than to wade through all the excess bug reports that will come in. Mozilla makes their daily builds easily available, which is great. OTOH, one of their biggest QA problems is getting people to handle the huge amount of bug reports -- many of which are dups, missing info, or bogus. -adam -- / adam maccabee trachtenberg | visit college life online \ \ [EMAIL PROTECTED] | http://www.student.com/ -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 09:39 AM 5/2/2001 -0400, Adam Trachtenberg wrote: On Wed, 2 May 2001, Andi Gutmans wrote: The COM problem would have been found IMO if we had released a bigger RC. I think the COM problem would have been found if somebody ran the test suite immediately before releasing 4.0.5 final. I think modifying the RC process to ensure that the last thing we do before releasing is to make sure the release passes the validation suite is a simpler step than opening the QA process to thousands of less qualified testers. The COM isn't in the test suite because it only runs on Windows. In any case, the test suite doesn't catch most problems. It is often tiny bugs which only happen under very certain setups. I know the QAT does its best to build and validate the RCs on as many platforms and configurations as possible. But, always adding in new features, to go along with bug fixes, makes it harder to gather all the testers together to review each RC. If we had less RCs or the RCs modified fewer files, it'd be easier to ensure like mistakes like COM don't slip through the cracks. We always have minor buglets in the RCs. It's much easier for the QAT to locate them internally than to wade through all the excess bug reports that will come in. Mozilla makes their daily builds easily available, which is great. OTOH, one of their biggest QA problems is getting people to handle the huge amount of bug reports -- many of which are dups, missing info, or bogus. Well we can experiment with RC1 of 4.0.6 and see what happens. I think we can only gain from doing this. If there are bug reports that come in which aren't relevant they would come in after the 4.0.6 release anyway. 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On Wed, 2 May 2001, Andi Gutmans wrote: At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. The COM problem would have been found IMO if we had released a bigger RC. That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Or are there binaries build for Winblows of each RC ? Another thing would be great, is that the snapshots of CVS were also found as binaries for Windoze. (Forgive me, I don't do Windows..=) --Jani -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 03:51 PM 5/2/2001 +0200, Jani Taskinen wrote: On Wed, 2 May 2001, Andi Gutmans wrote: At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. The COM problem would have been found IMO if we had released a bigger RC. That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Or are there binaries build for Winblows of each RC ? Another thing would be great, is that the snapshots of CVS were also found as binaries for Windoze. (Forgive me, I don't do Windows..=) Yes, that would definitely be nice and it used to exist on php4win.de. Hopefully when the site returns it'll start happening again. In any case, this problem isn't Windows or UNIX specific. It's just a question of not having enough people test the RC's. I don't think leaking some RC information to the PHP mailing list is a bad thing :) 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
We're going to have a Windows build machine at Zend, that will have automated builds (it's actually quite around the corner now). Once it's ready, we're going to have daily snapshots as well as RC builds all the time. Zeev At 16:51 2/5/2001, Jani Taskinen wrote: On Wed, 2 May 2001, Andi Gutmans wrote: At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. The COM problem would have been found IMO if we had released a bigger RC. That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Or are there binaries build for Winblows of each RC ? Another thing would be great, is that the snapshots of CVS were also found as binaries for Windoze. (Forgive me, I don't do Windows..=) --Jani -- 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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On Wed, 2 May 2001, Andi Gutmans wrote: Or are there binaries build for Winblows of each RC ? Another thing would be great, is that the snapshots of CVS were also found as binaries for Windoze. Yes, that would definitely be nice and it used to exist on php4win.de. Hopefully when the site returns it'll start happening again. Excuse me my stupidity, but why should it be their job to deliver these? IMO we should be providing them. Or is setting up some Windows machine to build them so hard? (I don't know shit about compiling on Windows :) I don't think leaking some RC information to the PHP mailing list is a bad thing :) The RC should also be announced on www.php.net as news item. With both Win32 binary and sources to be dowloaded there. --Jani -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 04:07 PM 5/2/2001 +0200, Jani Taskinen wrote: On Wed, 2 May 2001, Andi Gutmans wrote: Or are there binaries build for Winblows of each RC ? Another thing would be great, is that the snapshots of CVS were also found as binaries for Windoze. Yes, that would definitely be nice and it used to exist on php4win.de. Hopefully when the site returns it'll start happening again. Excuse me my stupidity, but why should it be their job to deliver these? IMO we should be providing them. Or is setting up some Windows machine to build them so hard? (I don't know shit about compiling on Windows :) Well we'll get one up and running at Zend. I don't think leaking some RC information to the PHP mailing list is a bad thing :) The RC should also be announced on www.php.net as news item. With both Win32 binary and sources to be dowloaded there. I think it's enough to announce it on the PHP mailing list with a short explanation of what RC means. We don't want the whole world to download the RC. Andi 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
The question is, if you think people will actually download the RC in order to test it (as opposed to using it) - why won't they join the QA team? At 17:11 2/5/2001, Sascha Schumann wrote: As I said, I don't think it's a big deal, but I think it will only have slight negative impact, and even slighter positive impact. I believe that people who are willing to download RC's and test them as such (i.e., send detailed and informative bug reports, or even positive summaries) would join the QA team. The ones will reach by announcing it on php-general/php.net/freshmeat are essentially people that will regard them as releases, and are likely to put them on production servers. Well, yeah. Lots of people in companies actually have test-servers with installations of their software where things can break without affecting any users. I'm not sure that we reach those users with our current QA process. But we might be able to do that by planting announcements on freshmeat.net-like sites. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 17:07 2/5/2001, Jani Taskinen wrote: On Wed, 2 May 2001, Andi Gutmans wrote: Yes, that would definitely be nice and it used to exist on php4win.de. Hopefully when the site returns it'll start happening again. Excuse me my stupidity, but why should it be their job to deliver these? IMO we should be providing them. Or is setting up some Windows machine to build them so hard? (I don't know shit about compiling on Windows :) Well, that's just the way things usually work; If you can donate something, you do it... Zeev -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
On Wed, 2 May 2001, Zeev Suraski wrote: The question is, if you think people will actually download the RC in order to test it (as opposed to using it) - why won't they join the QA team? Their job description might list test new software releases before putting them into production, and not join the PHP QA team. Joining the QA team for downloading a simple pre-release sounds a bit too much bureaucratic. And just to give an example. In the past, I've installed various pre-releases of the Linux kernel. If something broke, I reported it. But I don't think I would have ever joined a Linux QA team. Enabling more people to test RCs on a wider range of systems will hopefully produce more feedback and hence increase the quality of the release process. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
At 17:29 2/5/2001, Sascha Schumann wrote: On Wed, 2 May 2001, Zeev Suraski wrote: The question is, if you think people will actually download the RC in order to test it (as opposed to using it) - why won't they join the QA team? Their job description might list test new software releases before putting them into production, and not join the PHP QA team. Testing new software releases before putting them into production is pretty much a one sentence description of what 'Quality Assurance' is. Joining the QA team for downloading a simple pre-release sounds a bit too much bureaucratic. And just to give an example. In the past, I've installed various pre-releases of the Linux kernel. If something broke, I reported it. But I don't think I would have ever joined a Linux QA team. Enabling more people to test RCs on a wider range of systems will hopefully produce more feedback and hence increase the quality of the release process. I don't seem to recall Linux publishing far-reaching announcements about -pre versions. If you walked around the development mailing lists or the behind-the-scene web sites, you could hear about it, much like you can with PHP today. Zeev -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
Their job description might list test new software releases before putting them into production, and not join the PHP QA team. Testing new software releases before putting them into production is pretty much a one sentence description of what 'Quality Assurance' is. The main point here is that I think lowering the barrier is good and is more likely to produce good end results. I don't seem to recall Linux publishing far-reaching announcements about -pre versions. If you walked around the development mailing lists or the behind-the-scene web sites, you could hear about it, much like you can with PHP today. 10 announcements for the 2.2.19pre branch: http://freshmeat.net/branches/12527/ The same amount of 2.4-testing http://freshmeat.net/branches/12570/ - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On 2001-05-02 15:03:50, Zeev Suraski [EMAIL PROTECTED] wrote: We're going to have a Windows build machine at Zend, that will have automated builds (it's actually quite around the corner now). Once it's ready, we're going to have daily snapshots as well as RC builds all the time. That's good news; the cygwin test suite suggestion is probably still valid though. --Wez. -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On 2001-05-02 14:51:53, Jani Taskinen [EMAIL PROTECTED] wrote: That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. What would be great is a cross-compiler based on the cygwin package that would allow the developers to build win32 versions without having to have access to a win32 platform. That way they could at least test to make sure that it builds. Couple that with VMWare and you're flying :-) Seriously though, win32 is particular hard to do automated testing. Maybe we could use cygwin for running the test-suite under win32 and at least be able to use standard *nix tools? I haven't really looked at the test-suite, so this is just a (hopefully) helpful suggestion. --Wez. -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
At 05:34 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't seem to recall Linux publishing far-reaching announcements about -pre versions. If you walked around the development mailing lists or the behind-the-scene web sites, you could hear about it, much like you can with PHP today. Linux kernel pre-releases are usually publicized and easily downloadable. 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
On Wed, 2 May 2001, Zeev Suraski wrote: At 17:29 2/5/2001, Sascha Schumann wrote: On Wed, 2 May 2001, Zeev Suraski wrote: Their job description might list test new software releases before putting them into production, and not join the PHP QA team. Testing new software releases before putting them into production is pretty much a one sentence description of what 'Quality Assurance' is. I would rather describe QA as Making sure the release does have as least bugs as possible. IMO this is different then just testing RC's. I think a QA team should be the team who says Yes, release it or No, there are still some bugs left we want to fix. Of course, in order to do this, they need to test RC's. Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 03:38 PM 5/2/2001 +0100, Wez Furlong wrote: On 2001-05-02 14:51:53, Jani Taskinen [EMAIL PROTECTED] wrote: That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. What would be great is a cross-compiler based on the cygwin package that would allow the developers to build win32 versions without having to have access to a win32 platform. That way they could at least test to make sure that it builds. Couple that with VMWare and you're flying :-) Seriously though, win32 is particular hard to do automated testing. Maybe we could use cygwin for running the test-suite under win32 and at least be able to use standard *nix tools? I haven't really looked at the test-suite, so this is just a (hopefully) helpful suggestion. The nature of PHP on Windows is that it's really best to compile it with Visual C++. It uses native threading support and ISAPI support. I don't think it's a good or feasible idea to move to cygwin. 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
Okay guys, do whatever you want. Most people seem to agree with you. Zeev At 17:42 2/5/2001, Andi Gutmans wrote: At 05:34 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't seem to recall Linux publishing far-reaching announcements about -pre versions. If you walked around the development mailing lists or the behind-the-scene web sites, you could hear about it, much like you can with PHP today. Linux kernel pre-releases are usually publicized and easily downloadable. Andi -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
I would rather describe QA as Making sure the release does have as least bugs as possible. IMO this is different then just testing RC's. I think a QA team should be the team who says Yes, release it or No, there are still some bugs left we want to fix. Of course, in order to do this, they need to test RC's. Yes, the QA team might consider feedback from outsiders who have configurations which are not in wide deployment or not available to the QA team. Additionally, real-life scripts tend to stress PHP in ways no imaginable test framework can, so we get another dimension of pre-release testing. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
Zeev Suraski wrote: Testing new software releases before putting them into production is pretty much a one sentence description of what 'Quality Assurance' is. that's QA for their products usually and not so much for 3rd party components I don't seem to recall Linux publishing far-reaching announcements about -pre versions. If you walked around the development mailing lists or the behind-the-scene web sites, you could hear about it, much like you can with PHP today. o come on, all those 2.x.yPREz and .ACn announcements on freshmeat.net are not far-reaching? that's ridiculous! -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On 2001-05-02 15:43:57, Andi Gutmans [EMAIL PROTECTED] wrote: At 03:38 PM 5/2/2001 +0100, Wez Furlong wrote: Seriously though, win32 is particular hard to do automated testing. Maybe we could use cygwin for running the test-suite under win32 and at least be able to use standard *nix tools? The nature of PHP on Windows is that it's really best to compile it with Visual C++. It uses native threading support and ISAPI support. I don't think it's a good or feasible idea to move to cygwin. I agree about the compiling part, but cygwin isn't just a compiler - you get bash, sed, perl, awk and all those unix tools. I'm suggesting that perhaps the test suite could be run using those tools on a win32 platform. --Wez. -- 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]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On 2001-05-02 15:03:50, Zeev Suraski [EMAIL PROTECTED] wrote: We're going to have a Windows build machine at Zend, that will have automated builds (it's actually quite around the corner now). Once it's ready, we're going to have daily snapshots as well as RC builds all the time. That's good news; the cygwin test suite suggestion is probably still valid though. Another thing would be to branch into Borland C++, as thats also a strong windows based compiler, it opens compilation to a lot more people. I have to say, being able to download a prebuilt windows version would be good, heres a number of reasons why.. #1 What if the problem was with the MS VC++ on the machine that built it, rather than the actual code? #2 It does mean that for people like me who have access to Vis Studio but are not so familiar with it for whatever reason we can just download and test #3 Most people have access to a windows machine, thus opening for more of the people prepared to do proper QA to have a check on the windows stuff Liz -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
Wez; Is there another test suite other than the run-test.php script? (Which does run on Win32: TEST RESULT SUMMARY = Number of tests: 165 Tests skipped: 66 ( 40%) Tests failed: 22 ( 22%) Tests passed: 77 ( 78%) = Skipped 0 extensions. V:\php-4.0.5RC8 ) - Matt Wez Furlong [EMAIL PROTECTED] 05/02/01 12:02PM On 2001-05-02 15:43:57, Andi Gutmans [EMAIL PROTECTED] wrote: At 03:38 PM 5/2/2001 +0100, Wez Furlong wrote: Seriously though, win32 is particular hard to do automated testing. Maybe we could use cygwin for running the test-suite under win32 and at least be able to use standard *nix tools? The nature of PHP on Windows is that it's really best to compile it with Visual C++. It uses native threading support and ISAPI support. I don't think it's a good or feasible idea to move to cygwin. I agree about the compiling part, but cygwin isn't just a compiler - you get bash, sed, perl, awk and all those unix tools. I'm suggesting that perhaps the test suite could be run using those tools on a win32 platform. --Wez. -- 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] -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Can anyone make it easy to (via a good tutorial or some dsw) how to build and test php on windows ? If it only were as easy as in *nix :) -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Can anyone make it easy to (via a good tutorial or some dsw) how to build and test php on windows ? If it only were as easy as in *nix :) -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On Wed, 2 May 2001, Eduardo Dominguez wrote: That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Can anyone make it easy to (via a good tutorial or some dsw) how to build and test php on windows ? If it only were as easy as in *nix :) http://www.php.net/manual/en/install-windows.php -- alex -- 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] -- 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]
RE: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. The COM problem would have been found IMO if we had released a bigger RC. Andi The com problem wouldnt be there if 1) Phanto hadnt made such a big patch in RC7 2) He had tested it as I asked him to in an email saying I wouldnt have time to do so. unfortunatly I think this is a problem with the release process only x people should commit to branches these people should be people we trust and any other patch commited to the branch should be reverted until it can be verified by one of the X people (who test it before commiting) - James -- 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]
[PHP-DEV] RE: [PHP-QA] 4.0.6
Andi Gutmans wrote: I think it's enough to announce it on the PHP mailing list with a short explanation of what RC means. We don't want the whole world to download the RC. i would like to spread the news as far as possible Let's take it one step at a time. We should have an RC1 for 4.0.6 soon and we can see how the response from the PHP mailing lists are. That will already reach thousands. I would be very against this.. to me it seems silly, the current QA Team will have to spend 90% of their time running through the (maybe hundreds) of reports rather than testing. It makes more sense to me to try and attract more people who know what they are doing to the QA Team rather than having a fairly (maybe more :)) disorderly group of people testing from people who do not really know what they are doing.. - James -- 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]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
Seriously though, win32 is particular hard to do automated testing. Maybe we could use cygwin for running the test-suite under win32 and at least be able to use standard *nix tools? It already does run under windows. - James -- 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]
[PHP-DEV] RE: [PHP-QA] 4.0.6
At 06:34 PM 5/2/2001 +0100, James Moore wrote: Andi Gutmans wrote: I think it's enough to announce it on the PHP mailing list with a short explanation of what RC means. We don't want the whole world to download the RC. i would like to spread the news as far as possible Let's take it one step at a time. We should have an RC1 for 4.0.6 soon and we can see how the response from the PHP mailing lists are. That will already reach thousands. I would be very against this.. to me it seems silly, the current QA Team will have to spend 90% of their time running through the (maybe hundreds) of reports rather than testing. It makes more sense to me to try and attract more people who know what they are doing to the QA Team rather than having a fairly (maybe more :)) disorderly group of people testing from people who do not really know what they are doing.. You have tens of thousands of people testing releases today. What's the difference? 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]
[PHP-DEV] RE: [PHP-QA] 4.0.6
I would be very against this.. to me it seems silly, the current QA Team will have to spend 90% of their time running through the (maybe hundreds) of reports rather than testing. It makes more sense to me to try and attract more people who know what they are doing to the QA Team rather than having a fairly (maybe more :)) disorderly group of people testing from people who do not really know what they are doing.. You have tens of thousands of people testing releases today. What's the difference? The big difference is during a release process is the time scale. There are likley to be more bugs in an RC as well as people reporting bugs more rigerously (As well as probably reporting lots of bogus/dup bugs, which are very tedious to trawl through). If this is to happen (which I dont think it should) then we need to get the people to understand that RC testing is this this and this, not please test our latest RC and send feedback, if you come accross a problem then send the feedback here and here so it can be dealt with, please check the bugs database first etc. If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is released (remeber PHP users are incapable of reading anything more than about 10 words) lets use that; they then wont bother upgrading when the real 4.0.6 is released. This means we will start to get bug reports saying this isnt working in 4.0.6 when it has been fixed in the RC phase but is still present in the first RC. Everyone seems to be trying to fix the problem the wrong way. IMHO the problem here was with the Release Cycle not the amount of testing. Normally I test RC1 massivly then if there are problems I check for them in later RC's where people have said they have been fixed (or its decided that the bug should be fixed before the release). This time this didnt work for the single reason Phanto was unresposible and commited a huge (700 line commit) to RC7 and DIDNT test it. I asked him (as I asked sascha too) to when we decided to have RC8 (I think I cc'd the list) to test his changes throughly as I would not have time due to real work. Now Phanto obviously didnt do this, maybe someone should have caught it but I feel that by not testing Phanto invalidated a lot of hard work by the rest of the team to make 4.0.6 stable. I am certainly pissed off that this has happened as a lot of people put a lot of work into making sure 4.0.5 was stable and the problem here is not the testing but the developers commiting unneeded stuff to the RC branch. I feel we should only have x people commiting to the branch and if somthing is commited as late as the COM stuff was its up to the developer to test throughly otherwise its their head on the block. and remember the old proverb Too many cooks spoil the broth... - James -- 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]
Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
James Moore wrote: If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is released (remeber PHP users are incapable of reading anything more than about 10 words) lets use that; they then wont bother upgrading when the real 4.0.6 is released. This means we will start to get bug reports saying this isnt working in 4.0.6 when it has been fixed in the RC phase but is still present in the first RC. IMHO is's still better to have a RC that people do not update from then a pl1 that people do not update to (and we still have lots of error reports from people using versions way before 4.0.4, too) but if someone uses a RC and did not upgrade to the final release we can blame him if someone uses a release and didn't get the message that a pl1 is out it isn't that easy when using a RC you should be aware that a release (or a new RC) will be coming soon and that you should watch for it, especially if you have a problem with the RC when using a release there is nothing but experience with previous php 4 releases that gives you a clue that you should watch for a pl1 within days sure, some people don't get the clue whatever you do but with labeling something as release candidate, announcing it as such, and maybe adding bells and wistles to configure, make and the installers for precompiled windows versions (maybe even to every error message php generates) it should be possible to get the attention of everyone not totally clueless maybe we can agree on the following compromise? : - RC1 up to RCn announcements go to php-dev and QA only - as soon as things seem to work for QA we create RCn+1 or maybe PRC1 (public release candidate) and announce it to php-general this continues up to RCm or PRCm - when things have stabalzied even more we create [P]RCm+1 and announce it whereever we can - and finaly we do a release this would be just one additional step after all: take what we label as a release now and re-label it as (hopefully) final release candidate so that we hopefully get a release version which would otherwise be labeled as pl1 -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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]
[PHP-DEV] RE: [PHP-QA] 4.0.6
On Wed, 2 May 2001, James Moore wrote: I would be very against this.. to me it seems silly, the current QA Team will have to spend 90% of their time running through the (maybe hundreds) of reports rather than testing. It makes more sense to me to try and attract more people who know what they are doing to the QA Team rather than having a fairly (maybe more :)) disorderly group of people testing from people who do not really know what they are doing.. You have tens of thousands of people testing releases today. What's the difference? The big difference is during a release process is the time scale. There are likley to be more bugs in an RC as well as people reporting bugs more rigerously (As well as probably reporting lots of bogus/dup bugs, which are very tedious to trawl through). If this is to happen (which I dont think it should) then we need to get the people to understand that RC testing is this this and this, not please test our latest RC and send feedback, if you come accross a problem then send the feedback here and here so it can be dealt with, please check the bugs database first etc. If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is released (remeber PHP users are incapable of reading anything more than about 10 words) lets use that; they then wont bother upgrading when the real 4.0.6 is released. This means we will start to get bug reports saying this isnt working in 4.0.6 when it has been fixed in the RC phase but is still present in the first RC. Perhaps, however, I don't see that so feasible. During the 4.0 release cycle, the RC's were publicly released, and still, most people upgraded and used 4.0 final. The benefits of having many people test a Release Candidate, in my opinion, outweigh the negatives. Everyone seems to be trying to fix the problem the wrong way. IMHO the problem here was with the Release Cycle not the amount of testing. Normally I test RC1 massivly then if there are problems I check for them in later RC's where people have said they have been fixed (or its decided that the bug should be fixed before the release). This time this didnt work for the single reason Phanto was unresposible and commited a huge (700 line commit) to RC7 and DIDNT test it. I asked him (as I asked sascha too) to when we decided to have RC8 (I think I cc'd the list) to test his changes throughly as I would not have time due to real work. Now Phanto obviously didnt do this, maybe someone should have caught it but I feel that by not testing Phanto invalidated a lot of hard work by the rest of the team to make 4.0.6 stable. There's no point in wagging fingers. The fact is that this has happened before, thus the need for the patch level releases... Whatever the meaning for this serious bug sneaking in the release (as you said, its probably just a glitch in the Release Process), it would still be a good thing (separate from the problems with this release) to go ahead and make Release Candidates public on a site like Freshmeat. I am certainly pissed off that this has happened as a lot of people put a lot of work into making sure 4.0.5 was stable and the problem here is not the testing but the developers commiting unneeded stuff to the RC branch. I feel we should only have x people commiting to the branch and if somthing is commited as late as the COM stuff was its up to the developer to test throughly otherwise its their head on the block. There will always be glitches, educating people not to commit features to Release Candidates (unless absolutely necessary) and re-inforcing that, is, I think the better solution. and remember the old proverb Too many cooks spoil the broth... Given enough eyes, all bugs are shallow Its worked for Linux... -Sterling -- 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]
Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
At 08:36 PM 5/2/2001 +0200, Hartmut Holzgraefe wrote: James Moore wrote: If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is released (remeber PHP users are incapable of reading anything more than about 10 words) lets use that; they then wont bother upgrading when the real 4.0.6 is released. This means we will start to get bug reports saying this isnt working in 4.0.6 when it has been fixed in the RC phase but is still present in the first RC. IMHO is's still better to have a RC that people do not update from then a pl1 that people do not update to (and we still have lots of error reports from people using versions way before 4.0.4, too) but if someone uses a RC and did not upgrade to the final release we can blame him if someone uses a release and didn't get the message that a pl1 is out it isn't that easy when using a RC you should be aware that a release (or a new RC) will be coming soon and that you should watch for it, especially if you have a problem with the RC when using a release there is nothing but experience with previous php 4 releases that gives you a clue that you should watch for a pl1 within days sure, some people don't get the clue whatever you do but with labeling something as release candidate, announcing it as such, and maybe adding bells and wistles to configure, make and the installers for precompiled windows versions (maybe even to every error message php generates) it should be possible to get the attention of everyone not totally clueless maybe we can agree on the following compromise? : - RC1 up to RCn announcements go to php-dev and QA only - as soon as things seem to work for QA we create RCn+1 or maybe PRC1 (public release candidate) and announce it to php-general this continues up to RCm or PRCm - when things have stabalzied even more we create [P]RCm+1 and announce it whereever we can - and finaly we do a release this would be just one additional step after all: take what we label as a release now and re-label it as (hopefully) final release candidate so that we hopefully get a release version which would otherwise be labeled as pl1 I would make it a bit shorter. RC1 goes to php-dev QA. If there are no big messups RC2 goes to php-general and then we release. We can't slow down the release process to a halt and I think posting it on the whole net isn't such a good idea. 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]
[PHP-DEV] RE: [PHP-QA] 4.0.6
Try php4/tests/testcom Andi At 07:08 PM 5/2/2001 +0100, Liz wrote: This time this didnt work for the single reason Phanto was unresposible and commited a huge (700 line commit) to RC7 and DIDNT test it. I asked him (as I asked sascha too) to when we decided to have RC8 (I think I cc'd the list) to test his changes throughly as I would not have time due to real work. Now Phanto obviously didnt do this, maybe someone should have caught it but I feel that by not testing Phanto invalidated a lot of hard work by the rest of the team to make 4.0.6 stable. I put quite a bit of work in checking the releases for windows. But Im still very confused, I have put 4.0.5 on a couple of machines and still see working pages with com stuff on them, I've been told the com test scripts fail, but can someone clarify the exact problem? I'll even look at the code if it helps, but, at the moment, I still havent seen a problem.. Am I being thick? While in some respects an ideal world a more public release would be a good thing, we have to remember that quite a lot of the people who grab it are people like my fiance, people who feel they NEED to have a later version, even if it fixes nothing they have issues with and only introduces more problems. But unlike my fiance, they might not even be that computer literate. We cant assume that they are in a position to report back with reasonable information bugs, people who have joined the QA have promised to test and give good feedback.. We need to rely on them (me).. However, with nice statements like COM doesnt work, it would be helpful if I could look at it in more detail. Liz -- 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]
[PHP-DEV] Re: [PHP-QA] 4.0.6
On Wed, May 02, 2001 at 06:58:57PM +0100, James Moore wrote: I would be very against this.. to me it seems silly, the current QA Team will have to spend 90% of their time running through the (maybe hundreds) of reports rather than testing. It makes more sense to me to try and attract more people who know what they are doing to the QA Team rather than having a fairly (maybe more :)) disorderly group of people testing from people who do not really know what they are doing.. You have tens of thousands of people testing releases today. What's the difference? The big difference is during a release process is the time scale. There are likley to be more bugs in an RC as well as people reporting bugs more rigerously (As well as probably reporting lots of bogus/dup bugs, which are very tedious to trawl through). Exactly. While it would be nice to think that broadening the audience of the testing cycle would yield more bug finding, I fear it would inundate the bug database with only marginally useful bug reports. The number of bug reports that boil down to My script doesn't work! would certainly increase. Reports that extension X doesn't work, but provide no substantial information would increase, and so on. I don't see inviting this wider audience as providing enough beneficial information to justify the work of clearing away the less useful reports. Normally I test RC1 massively then if there are problems I check for them in later RC's where people have said they have been fixed (or its decided that the bug should be fixed before the release). This time this didnt work for the single reason Phanto was unresposible and commited a huge (700 line commit) to RC7 and DIDNT test it. I asked him (as I asked sascha too) to when we decided to have RC8 (I think I cc'd the list) to test his changes throughly as I would not have time due to real work. Now Phanto obviously didnt do this, maybe someone should have caught it but I feel that by not testing Phanto invalidated a lot of hard work by the rest of the team to make 4.0.6 stable. This sort of thing simply shouldn't happen, imho. If the QA team's word is to mean anything, they need to have the authority to say No, that needs to be removed. If they don't have that authority, then how can they be expected to say We have tested RC8, and it is ready to be released.? I am certainly pissed off that this has happened as a lot of people put a lot of work into making sure 4.0.5 was stable and the problem here is not the testing but the developers commiting unneeded stuff to the RC branch. I feel we should only have x people commiting to the branch and if somthing is commited as late as the COM stuff was its up to the developer to test throughly otherwise its their head on the block. I can understand why it would be frustrating to see what could amount to an undermining of the testing cycle, but I don't think shifting blame to the developers is the best solution. This will only lead to animosity over the quality of releases. What I'd like to see instead is for the QA team to own the release cycle. That is, as soon as RC's start being rolled, QA has the right to determine if a commit shouldn't go in. Without that control, it seems to me that their hands are being tied. Matt -- 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]
Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
I think the key thing with RCs was touched on by James - we need to be complete bastards as to what's allowed in after RC1 otherwise every RC is really RC1, however human nature and available time means RCN (where N1) gets less testing than RC1. Can we set karma levels on the RC branch such that only a very restricted set of people can commit, and anyone who wants to submit a fix has to argue and explain to get it in, and anyone who wants to commit a feature can be sent away with a flea in their ear. Also for Windows testing it would help if someone who understands the test system posts a step by step hand holding list of things to do to make it work on Windows - it will then get used much more. Also on the test suite, it always worries me that it tests the executable rather than via the web server/browser and so must miss out on testing loads of functionality as well as testing in the wrong environment. Would it be possible to modify the tests so that optionally they can be run via a browser (even if it means clicking on a load of 'next' buttons). Test output could still be spooled to a single file so that there is a central pool of results which can be reported back to the list. Cheers -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
Matt McClanahan wrote: I don't see inviting this wider audience as providing enough beneficial information to justify the work of clearing away the less useful reports. right now we invite this wider audience the day we release a 'release' and again and again we end up with a .pl1 i just want to get into some process that shifts labels here making what we call 'release' now the final release candidate so that we end up with a release that deserves this name without having an .pl1 attached if you do not want to see useless bug reports you should not release at all -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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]
[PHP-DEV] RE: [PHP-QA] 4.0.6
Try php4/tests/testcom
OK, that 1 test doesnt work..
However the following does. Which is why I was asking for clarification. This
following code is essential to me, however, I dont make word documents on the
fly.. although I now hate everyone for giving me even more stupid ideas than I
already had.
?php
$keywords=explode( ,$SearchString);
$q = new COM(ixsso.Query);
$n = new COM(ixsso.Util);
$q-Query = @contents Server;
$q-Catalog = its;
$q-SortBy = rank[d];
$q-Columns = DocTitle, vpath;
$q-MaxRecords = 200;
$q-Query=$SearchString;
$n-AddScopeToQuery($q,/,deep);
$rs = $q-CreateRecordSet(nonsequential);
$rs-PageSize = 10;
if (!$rs-EOF) {
$c = 0;
while (!($rs-EOF) ($c$rs-PageSize)) {
$fld=$rs-Fields(1);
echo $fld-Value;
$fld=$rs-Fields(2);
$link=$fld-Value;
$rs-MoveNext();
$c++;
}
$rs-Close();
} else {
echo no records;
}
?
So the statement COM doesnt work isnt entirely valid. Bits of it dont
work...
Liz
--
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]
[PHP-DEV] RE: [PHP-QA] 4.0.6
?php
$keywords=explode( ,$SearchString);
$q = new COM(ixsso.Query);
$n = new COM(ixsso.Util);
$q-Query = @contents Server;
$q-Catalog = its;
$q-SortBy = rank[d];
$q-Columns = DocTitle, vpath;
$q-MaxRecords = 200;
$q-Query=$SearchString;
$n-AddScopeToQuery($q,/,deep);
$rs = $q-CreateRecordSet(nonsequential);
$rs-PageSize = 10;
if (!$rs-EOF) {
$c = 0;
while (!($rs-EOF) ($c$rs-PageSize)) {
$fld=$rs-Fields(1);
echo $fld-Value;
$fld=$rs-Fields(2);
$link=$fld-Value;
$rs-MoveNext();
$c++;
}
$rs-Close();
} else {
echo no records;
}
?
That code works from a web browser, it would suggest that its not getting the
correct handle as its not a windows app when run from command line..
I could of course be very wrong. Especially as the testcom doesnt crash from a
browser
--
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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] 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 -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On Wed, May 02, 2001 at 09:03:00PM +0200, Hartmut Holzgraefe wrote: Matt McClanahan wrote: I don't see inviting this wider audience as providing enough beneficial information to justify the work of clearing away the less useful reports. right now we invite this wider audience the day we release a 'release' and again and again we end up with a .pl1 James already addressed this in the top of his post that I responed to, and quoted. Release cycles are supposed to happen in a much shorter period of time than the lifetime of an actual release. Given that releases can't expect to tackle all known bugs, the goal becomes hitting a reasonable number of bugs, such that the release cycle doesn't take too long, while still making good progress on the number of outstanding bugs. i just want to get into some process that shifts labels here making what we call 'release' now the final release candidate so that we end up with a release that deserves this name without having an .pl1 attached if you do not want to see useless bug reports you should not release at all Such bugs are inevitable, against releases. However there's no reason that such bugs have to be inevitable against release candidates when the people testing them are all (theoretically) knowledgable about how to submit a good bug report. Matt -- 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]
Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
How about we stop this thread and invest all of this time in going over the bugs database and fixing bugs? :) We do spend too much time typing and not enough time resolving bugs... (me included sometimes). I think although not everyone agrees we do have more or less a concensus on: a) Being even more careful in what goes into the release branch. The patches should be reviewed more especially when they are coming from people who aren't known as core developers. Also patches from core developers should be reviewed but if Sascha *needs* a patch for his ircg in the next release, even if it's a new feature, I think it's OK. b) Let's try and enlarge the amount of people who test RC's but not by too many. We can do this via php-general@ writing strict guidelines in the Email of what should and should not be reported; and how it is reported. If it is not reported the right way we can just nuke it from the bugs database until after the release. Now let's go and catch those bugs and start the 4.0.6 release cycle soon :) 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]
Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
At 19:54 02.05.2001 +0100, Phil Driscoll wrote: Also for Windows testing it would help if someone who understands the test system posts a step by step hand holding list of things to do to make it work on Windows - it will then get used much more. you can now (start the tests|look at test results) from within VC. just start the build for testsuite, and open results.txt after it finished. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- 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]
Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
Andi wrote: At 01:16 PM 5/2/2001 -0600, Zak Greant wrote: [snip] I don't think it's too realistic :) I prefer having the php-general guys test it on their development machine's. Perhaps we should just encourage the brave and foolhardy to run it on a production machines. :) --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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
At 22:38 2/5/2001, Andi Gutmans wrote: How about we stop this thread and invest all of this time in going over the bugs database and fixing bugs? :) I'll drink to that :) -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
I think very much like James, that we're trying to fix something that wasn't broken. Ten RC's and twenty PRC's won't have done anything, if between the last PRC and the final release code got changed. James put what I thought in clearer words (and with much more passion :), I agree with every word he said. Andi - php-general@ today is so full of newbies that it's not a very good place to start with either. There may be smaller teams, PHP user groups or something along these lines, that will be willing to take part in the QA process. I don't think that a random group of a few thousand users is a good idea to start with. Zeev At 21:36 2/5/2001, Hartmut Holzgraefe wrote: James Moore wrote: If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is released (remeber PHP users are incapable of reading anything more than about 10 words) lets use that; they then wont bother upgrading when the real 4.0.6 is released. This means we will start to get bug reports saying this isnt working in 4.0.6 when it has been fixed in the RC phase but is still present in the first RC. IMHO is's still better to have a RC that people do not update from then a pl1 that people do not update to (and we still have lots of error reports from people using versions way before 4.0.4, too) but if someone uses a RC and did not upgrade to the final release we can blame him if someone uses a release and didn't get the message that a pl1 is out it isn't that easy when using a RC you should be aware that a release (or a new RC) will be coming soon and that you should watch for it, especially if you have a problem with the RC when using a release there is nothing but experience with previous php 4 releases that gives you a clue that you should watch for a pl1 within days sure, some people don't get the clue whatever you do but with labeling something as release candidate, announcing it as such, and maybe adding bells and wistles to configure, make and the installers for precompiled windows versions (maybe even to every error message php generates) it should be possible to get the attention of everyone not totally clueless maybe we can agree on the following compromise? : - RC1 up to RCn announcements go to php-dev and QA only - as soon as things seem to work for QA we create RCn+1 or maybe PRC1 (public release candidate) and announce it to php-general this continues up to RCm or PRCm - when things have stabalzied even more we create [P]RCm+1 and announce it whereever we can - and finaly we do a release this would be just one additional step after all: take what we label as a release now and re-label it as (hopefully) final release candidate so that we hopefully get a release version which would otherwise be labeled as pl1 -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On 2 May 2001 06:20:41 -0700, [EMAIL PROTECTED] (Zeev Suraski) wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I have tried to report bugs - even fixed 3 in the Interbase module, but I haven't heard or seen any reaction. Do these fixes have any chance of being incorporated in a release soon, or is bugfixing only for the _official_ developers? By the way: Bug report #9257 and #10292 regarding ./ext/interbase/interbase.c have been identified and fixed :-) Fixes are also reported in #10458. Regards Lars Westermann I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. Zeev At 16:08 2/5/2001, Hartmut Holzgraefe wrote: Zeev Suraski wrote: I don't think that's a good idea, because then people will treat them as releases. thats just a matter of labeling and announcement message I think that the way things are currently, plus the natural growth of the QA team, are the right way to go. IMHO the current peak in new bug reports tells a different story -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
At 22:46 02.05.2001 +0300, Zeev Suraski wrote: I think very much like James, that we're trying to fix something that wasn't broken. Ten RC's and twenty PRC's won't have done anything, if between the last PRC and the final release code got changed. the com support is/was broken for 6 weeks... daniel James put what I thought in clearer words (and with much more passion :), I agree with every word he said. Andi - php-general@ today is so full of newbies that it's not a very good place to start with either. There may be smaller teams, PHP user groups or something along these lines, that will be willing to take part in the QA process. I don't think that a random group of a few thousand users is a good idea to start with. Zeev At 21:36 2/5/2001, Hartmut Holzgraefe wrote: James Moore wrote: If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is released (remeber PHP users are incapable of reading anything more than about 10 words) lets use that; they then wont bother upgrading when the real 4.0.6 is released. This means we will start to get bug reports saying this isnt working in 4.0.6 when it has been fixed in the RC phase but is still present in the first RC. IMHO is's still better to have a RC that people do not update from then a pl1 that people do not update to (and we still have lots of error reports from people using versions way before 4.0.4, too) but if someone uses a RC and did not upgrade to the final release we can blame him if someone uses a release and didn't get the message that a pl1 is out it isn't that easy when using a RC you should be aware that a release (or a new RC) will be coming soon and that you should watch for it, especially if you have a problem with the RC when using a release there is nothing but experience with previous php 4 releases that gives you a clue that you should watch for a pl1 within days sure, some people don't get the clue whatever you do but with labeling something as release candidate, announcing it as such, and maybe adding bells and wistles to configure, make and the installers for precompiled windows versions (maybe even to every error message php generates) it should be possible to get the attention of everyone not totally clueless maybe we can agree on the following compromise? : - RC1 up to RCn announcements go to php-dev and QA only - as soon as things seem to work for QA we create RCn+1 or maybe PRC1 (public release candidate) and announce it to php-general this continues up to RCm or PRCm - when things have stabalzied even more we create [P]RCm+1 and announce it whereever we can - and finaly we do a release this would be just one additional step after all: take what we label as a release now and re-label it as (hopefully) final release candidate so that we hopefully get a release version which would otherwise be labeled as pl1 -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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] /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
At 10:46 PM 5/2/2001 +0300, Zeev Suraski wrote: I think very much like James, that we're trying to fix something that wasn't broken. Ten RC's and twenty PRC's won't have done anything, if between the last PRC and the final release code got changed. James put what I thought in clearer words (and with much more passion :), I agree with every word he said. Andi - php-general@ today is so full of newbies that it's not a very good place to start with either. There may be smaller teams, PHP user groups or something along these lines, that will be willing to take part in the QA process. I don't think that a random group of a few thousand users is a good idea to start with. Yeah but we can try it once. If we see that it's a disaster we'll stop and what we might have earned from it is having some of the more knowledgable guys from php-general@ hear about php-qa@ and joining. As I said, you might be right but I think it's worth a try. 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
At 09:52 PM 5/2/2001 +0200, Daniel Beulshausen wrote: At 22:46 02.05.2001 +0300, Zeev Suraski wrote: I think very much like James, that we're trying to fix something that wasn't broken. Ten RC's and twenty PRC's won't have done anything, if between the last PRC and the final release code got changed. the com support is/was broken for 6 weeks... And the breaker has fled and isn't fixing it :) 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
At 22:52 2/5/2001, Daniel Beulshausen wrote: At 22:46 02.05.2001 +0300, Zeev Suraski wrote: I think very much like James, that we're trying to fix something that wasn't broken. Ten RC's and twenty PRC's won't have done anything, if between the last PRC and the final release code got changed. the com support is/was broken for 6 weeks... So the bug is not related to the big patch from phanto from a week ago? Zeev -- 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
At 22:57 02.05.2001 +0300, Zeev Suraski wrote: At 22:52 2/5/2001, Daniel Beulshausen wrote: At 22:46 02.05.2001 +0300, Zeev Suraski wrote: I think very much like James, that we're trying to fix something that wasn't broken. Ten RC's and twenty PRC's won't have done anything, if between the last PRC and the final release code got changed. the com support is/was broken for 6 weeks... So the bug is not related to the big patch from phanto from a week ago? he merged it a week ago, but it existed in the main branch for 6 weeks. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- 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]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
At 10:57 PM 5/2/2001 +0300, Zeev Suraski wrote: At 22:52 2/5/2001, Daniel Beulshausen wrote: At 22:46 02.05.2001 +0300, Zeev Suraski wrote: I think very much like James, that we're trying to fix something that wasn't broken. Ten RC's and twenty PRC's won't have done anything, if between the last PRC and the final release code got changed. the com support is/was broken for 6 weeks... So the bug is not related to the big patch from phanto from a week ago? It is but 6 weeks have passed :) 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]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
Wez Furlong [EMAIL PROTECTED] 05/02/01 12:02PM get bash, sed, perl, awk and all those unix tools. I'm suggesting that perhaps the test suite could be run using those tools on a win32 platform. On 2001-05-02 18:09:07, Matt White [EMAIL PROTECTED] wrote: Is there another test suite other than the run-test.php script? Errr, probably not. Sorry for my complete ignorance of the test suite and how it works! --Wez. -- 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]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
the com support is/was broken for 6 weeks... So the bug is not related to the big patch from phanto from a week ago? Well, I have a server with 4.0.4RC6 and all is happy.. so it was deffinately fine then! I didnt upgrade it to as I wasnt able (its actually a kinda live server but its not in a location where I can change it that easily) I am seeing that some COM stuff is now hanging with 4.0.5, however, a lot of the stuff I use day to day is different on Personal IIS5 than the the full version. So, I'll try and look at the difference in code and see if I can help pin down any apparent problems, it seems tobe the $word-Visible=1; line, if you skip that, it cant do a couple of other things and then allows you to Quit.. Liz -- 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]
Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
On Wed, May 02, 2001 at 01:40:28PM -0600, Zak Greant wrote: Perhaps we should just encourage the brave and foolhardy to run it on a production machines. :) s/brave/mad/. That's what I have a test-machine for which runs RC's with apps used on our main-site being hit by scripts. True, it doesn't emulate a production-Environment completly, but comes close enough to it. -fkr -- gpg-fingerprint: 076E 1E87 3E05 1C7F B1A0 8A48 0D31 9BD3 D9AC 74D0 |http://www.hazardous.org/ | whois -h whois.ripe.de FKR-RIPE | |all your base are belong to us | shame on me | fkr@IRCnet | -- 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]
