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

2001-06-22 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-06-22 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-06-21 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-06-21 Thread 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 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)

2001-05-03 Thread 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 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

2001-05-03 Thread 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]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 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)

2001-05-02 Thread 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 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

2001-05-02 Thread 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 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)

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 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)

2001-05-02 Thread 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 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)

2001-05-02 Thread 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 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)

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 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)

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 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)

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)

2001-05-02 Thread 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 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)

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED] 
For additional commands, e-mail: [EMAIL PROTECTED] 
To contact the list administrators, e-mail: [EMAIL PROTECTED] 



--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 N1)
gets less testing than RC1.

Can we set karma levels on the RC branch such that only a very restricted
set of people can commit, and anyone who wants to submit a fix has to argue
and explain to get it in, and anyone who wants to commit a feature can be
sent away with a flea in their ear.

Also for Windows testing it would help if someone who understands the test
system posts a step by step hand holding list of things to do to make it
work on Windows - it will then get used much more.

Also on the test suite, it always worries me that it tests the executable
rather than via the web server/browser and so must miss out on testing loads
of functionality as well as testing in the wrong environment. Would it be
possible to modify the tests so that optionally they can be run via a
browser (even if it means clicking on a load of 'next' buttons). Test output
could still be spooled to a single file so that there is a central pool of
results which can be reported back to the list.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 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

2001-05-02 Thread 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 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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


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


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




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

2001-05-02 Thread 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 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]