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