Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!

[Sascha Schumann]

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

[Wico de Leeuw]

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

[Sascha Schumann]

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

[Phil Driscoll]

Just built 4.0.6 on NT4 and tested with my code under IIS. No problems found.
When I ran the test suite, there were a few errors, but I don't know whether 
or not these are expected on Win32. I've attached the output of the test.

Cheers
-- 
Phil Driscoll


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests
==
dirname test (dirname.phpt)  ... failed


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests/basic

Trivial "Hello World" test   ... passed
Simple POST Method test  ... passed
GET and POST Method combined ... passed
Two variables in POST data   ... passed
Three variables in POST data ... passed
Add 3 variables together and print result... passed
Multiply 3 variables and print result... passed
Divide 3 variables and print result  ... passed
Subtract 3 variables and print result... passed
Testing | and & operators... passed
Testing $argc and $argv handling ... passed


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests/classes
==
Classes general test ... passed
Classes inheritance test ... passed


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests/func
===
Strlen() function test   ... passed
Static variables in functions... passed
General function test... passed
General function test... passed
Testing register_shutdown_function() ... passed


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests/lang
===
Simple If condition test ... passed
Simple While Loop Test   ... passed
Simple Switch Test   ... passed
Simple If/Else Test  ... passed
Simple If/ElseIf/Else Test   ... passed
Nested If/ElseIf/Else Test   ... passed
Function call with global and static variables   ... passed
Testing recursive function   ... passed
Testing function parameter passing   ... passed
Testing function parameter passing with a return value   ... passed
Testing nested functions ... passed
Testing stack after early function return... passed
Testing eval function... passed
Testing eval function inside user-defined function   ... passed
Testing include (015.phpt)   ... failed
Testing user-defined function in included file (016.phpt)... failed
Testing user-defined function falling out of an If into another  ... passed
eval() test  ... passed
eval() test  ... passed
Switch test 1... passed
Switch test 2... passed
Switch test 3... passed
Regression test (023.phpt)   ... failed
Looped regression test (may take a while) (024.phpt) ... failed
Mean recursion test  ... passed
Testing string scanner confirmance   ... passed
Testing do-while loop... passed
Testing calling user-level functions from C  ... passed
OO Bug Test (Bug #7515) (029.phpt)   ... failed
$this in constructor test... passed


Warning:  Undefined variable:  ext_found in ..\run-tests.php on line 307
Running tests in tests/strings
==
String functions

Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!

[Wico de Leeuw]

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

[Hellekin O. Wolf]

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

[Phil Driscoll]

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

[Richard Lynch]

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 (fwd)

[Richard Lynch]

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

[Felix Kronlage]

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

[Lars Westermann]

On 2 May 2001 13:08:06 -0700, [EMAIL PROTECTED] (Andi Gutmans) wrote:

>I suggest the following. Create one nice big diff with all of your fixes. 
>Mail it to the extension maintainers for double checking with cc: to 
>php-dev. If they don't reply in a reasonable time I'll apply the patch and 
>assume you know what you're doing :)
>
>Andi
>
Thanks very much for the reply.

I have patched ./ext/interbase/interbase.c, and here is my patch
(against interbase.c ver. 1.48 (php404pl1)):

$ diff interbase.c interbase.orig.c
1731d1730
<   val->value.str.val[len] = 0;
1736c1735
<  val->value.str.val = php_addslashes(val->value.str.val, len, &len,
1);
---
>  val->value.str.val = php_addslashes(val->value.str.val, len, &len, 0);
1754d1752
<
1784,1785c1782,1783
< val->value.str.len = sprintf(string_data, "%Ld.%0*Ld",
< (ISC_INT64) (*((ISC_INT64 *)data) / (int) pow(10.0, (double)
-scale)), -scale,
---
> val->value.str.len = sprintf(string_data, "%Ld.%Ld",
> (ISC_INT64) (*((ISC_INT64 *)data) / (int) pow(10.0, (double) -scale)),
$


The first diff forces a NULL-termination of the string after a
strncpy() (common practice)
Next diff removes a potential memoryleak, when working with magic
quotes.
Third diff formats NUMERIC correctly to the right of the decimal point
(field width , - scale) wasn't used to place the fractional part in
the correct place)

Hope this information is sufficient.


/Lars

PS: And the patches DO work - we couldn't do without them! :-)


-- 
PHP Development Mailing List 
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

[Liz]

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

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

I suggest the following. Create one nice big diff with all of your fixes. 
Mail it to the extension maintainers for double checking with cc: to 
php-dev. If they don't reply in a reasonable time I'll apply the patch and 
assume you know what you're doing :)

Andi

At 09:53 PM 5/2/2001 +0200, Lars Westermann wrote:
>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 
>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 
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

[Daniel Beulshausen]

At 22:55 02.05.2001 +0300, Andi Gutmans wrote:
>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 :)

that isn't the problem, the problem is that it'll take some time to step 
behind the code :)

daniel

/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


-- 
PHP Development Mailing List 
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

[Andi Gutmans]

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

[Daniel Beulshausen]

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

[Zeev Suraski]

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

[Andi Gutmans]

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

[Andi Gutmans]

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

[Daniel Beulshausen]

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

[Lars Westermann]

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

[Zeev Suraski]

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

[Zeev Suraski]

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

[Zak Greant]

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

[Daniel Beulshausen]

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

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

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

[Andi Gutmans]

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

[Liz]

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

[Zak Greant]

Andi wrote:
[snip]
> That was really a big disappointment as people did such a good job on the
> release cycle IMO.
> No doubt it shouldn't have slipped in.
> And if it doesn't get fixed soon we should revert to the old version of
the
> COM module.

How much testing is the QA team actually doing?  I would suspect that
the
majority of the QA team follows the same slack process that I follow.

1.) build the latest release
2.) make test
3.) look at phpinfo()
4.) see what happens to a few scripts

Am I right? :)

We should be testing the RC's against large bodies of working
code that real users are using. This is tough to do - no one wants to
break a working site.

How difficult (and useful) would it be for us to have a system like
the one describe below.

The standard PHP SAPIs and CGI executable are replaced by shell that
maintains environment data and passes it to an RC.  The RC attempts
to handle the request.  If it fails, the shell passes the same request
is passed to a stable version of PHP, and the failure is logged,
along with the environment data, etc...

The user request may be slowed, but is still served.  The shell
could include threshold settings so that we stop passing requests
known to break the RC after a certain number of requests...

By co-operating with various site owners, we could get the RCs into
environments where they server millions of hits in a day in a broad
range of situations.

Anyone think that this blueskying is useful or possible?

--zak


-- 
PHP Development Mailing List 
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

[Liz]

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

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

[Hartmut Holzgraefe]

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

[Phil Driscoll]

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 N>1)
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 
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

[Matt McClanahan]

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

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

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

At 06:58 PM 5/2/2001 +0100, James Moore wrote:
> > 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.

I don't think it should be put on freshmeat like some people suggested. I 
just think that getting some more people from the PHP mailing lists to test 
it is a good thing. We do want to have bugs reported during the RC cycle 
and not afterwards.


>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"...

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.

Andi


-- 
PHP Development Mailing List 
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

[Sterling Hughes]

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

[Hartmut Holzgraefe]

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

[Liz]

> 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 Development Mailing List 
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

[James Moore]

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

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

http://www.php.net/install

its all there under the windows section.. why dont people read the manual??

- James

> -Original Message-
> From: Eduardo Dominguez [mailto:[EMAIL PROTECTED]]
> Sent: 02 May 2001 18:22
> To: [EMAIL PROTECTED]
> Subject: 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]


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

[James Moore]

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

[James Moore]

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

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

[Alexander Feldman]

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

[Eduardo Dominguez]

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

[Eduardo Dominguez]

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

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

[Liz]

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

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

[Hartmut Holzgraefe]

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

[Andi Gutmans]

At 05:48 PM 5/2/2001 +0300, Zeev Suraski wrote:
>Okay guys, do whatever you want.  Most people seem to agree with you.

At least you'll be able to give us the "I told you so" speech if it makes 
things worse :)

Andi


-- 
PHP Development Mailing List 
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)

[Sascha Schumann]

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

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

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

[derick]

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

[Andi Gutmans]

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

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

[Wez Furlong]

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

[Sascha Schumann]

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

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

[Sascha Schumann]

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

At 04:20 PM 5/2/2001 +0200, Hartmut Holzgraefe 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.

Andi


-- 
PHP Development Mailing List 
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

[Hartmut Holzgraefe]

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

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

-- 
PHP Development Mailing List 
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)

[Andi Gutmans]

At 05:15 PM 5/2/2001 +0300, 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?

Because they can't really be bothered with being part of the QA team and 
seeing all the Emails. But they do want to run the RC on their test server 
to make sure they are ready to upgrade and that they can upgrade (And of 
course they want to help out).

Andi


-- 
PHP Development Mailing List 
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

[Zeev Suraski]

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

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

[Andi Gutmans]

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

[Sascha Schumann]

> 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 Development Mailing List 
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

[Jani Taskinen]

Hehe..I was just gonna suggest that Zend could do this... :)
This is really great news.

--Jani

On Wed, 2 May 2001, Zeev Suraski 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.
>
>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 
>>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 
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

[Jani Taskinen]

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

[Zeev Suraski]

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

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

[Jani Taskinen]

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

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

[Adam Trachtenberg]

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

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

[Sascha Schumann]

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

[Zeev Suraski]

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

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

[Zeev Suraski]

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

[Hartmut Holzgraefe]

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

-- 
PHP Development Mailing List 
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]

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

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

[Zeev Suraski]

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

[Hartmut Holzgraefe]

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]