# PHP Release Process Sucks

- Thread: https://externals.io/message/23367
- Original archive: https://news-web.php.net/php.internals/23367
- Started by Stefan Esser on 2006-05-15T13:39:25+00:00
- Messages: 54
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/23367.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #23373 — Steph Fox — 2006-05-14T16:08:51+00:00

URL: https://externals.io/message/23367#23373 · In reply to: #23367

Stefan,

Ironically
> after that incident another Zend man came forward and dares to say "I
> don't trust our core testers anymore"

He dared to say it because there's a QA mechanism in place that isn't 
working - AKA a bunch of application developers testing Release Candidates 
on their real-world applications rather than testing only against PHP's own 
test suite. If any of them had done so, they would have picked up the 
problem with user input arrays straight away. They evidently didn't, and 
didn't.

I don't see what's so 'ironic' about mentioning that, and I certainly don't 
think it's any kind of bad thing that Tony went on to request extra time 
prior to 5.1.4's being tagged so that he could download a bunch of PHP 
applications out there and run his own real-world tests.


- Steph

---

## #23395 — Steph Fox — 2006-05-14T18:22:03+00:00

URL: https://externals.io/message/23367#23395 · In reply to: #23393

> Sebastian Bergmann wrote:
> > […]
>
> Strike that, I was educated about this on IRC just now. My initial
> point is still valid to some degree, IMHO: just because Stefan's work
> does not go into cvs.php.net does not mean that he is not helping to
> make PHP better (more secure in his case).

True, but it'd be far more useful to have Stefan's feedback at RC stage 
rather than at post-release stage. We all know he's good at what he does.

- Steph

---

## #23367 — Stefan Esser — 2006-05-15T13:39:25+00:00

URL: https://externals.io/message/23367#23367

Hello,

okay, mistakes happen everyday but it really sucks that PHP.net
continues trying to hide mistakes.

1) PHP 5.1.4 was released with a nonsense announcement claiming that
there was only a problem with POST arrays or POST fileuploads.
    -> In reality a paid Zend developer had destroyed the handling of
arrays in any kind of user input in PHP 5.1.3 completely. Ironically
after that incident another Zend man came forward and dares to say "I
don't trust our core testers anymore"
2) PHP 5.1.4 was lacking the PEAR installer which resulted in make
install downloading the file from the web.
    a) this part should be removed from the make file completlely
because 'make install' is usually executed as root and under no
circumstances should download a file from an insecure HTTP source.
    b) this fact was again hidden by silently replacing the PHP 5.1.4
tarball with a new one, after the other one was out for more than a week.

PHP.net is more and more turning into Microsoft (more than 3 months to
resolve critical security problems). I guess that comes with the
involvement of Enterprise companies.

Yours,
Stefan Esser

---

## #23369 — Ilia Alshanetsky — 2006-05-15T15:36:30+00:00

URL: https://externals.io/message/23367#23369 · In reply to: #23367

> Hello,
>
> okay, mistakes happen everyday but it really sucks that PHP.net
> continues trying to hide mistakes.
>
> 1) PHP 5.1.4 was released with a nonsense announcement claiming that
> there was only a problem with POST arrays or POST fileuploads.
>     -> In reality a paid Zend developer had destroyed the handling of
> arrays in any kind of user input in PHP 5.1.3 completely. Ironically
> after that incident another Zend man came forward and dares to say "I
> don't trust our core testers anymore"

That is what the bug reports that appeared in relation to the problem  
were complaining about, the announcement was tailored to address  
issues raised by those people.

> 2) PHP 5.1.4 was lacking the PEAR installer which resulted in make
> install downloading the file from the web.
>     a) this part should be removed from the make file completlely
> because 'make install' is usually executed as root and under no
> circumstances should download a file from an insecure HTTP source.

We didn't have an automated process for including PEAR's phar file  
in, it is now part of the release generation script. As far as  
automated download, for full releases this will not be necessary in  
the future as it will be included by default. As far as the phar  
download, I think it either needs to require a confirmation prompt or  
simply not done automatically, either way is fine by me.

>     b) this fact was again hidden by silently replacing the PHP 5.1.4
> tarball with a new one, after the other one was out for more than a  
> week.
>

The code in the release did not change on bit, the only change was  
the inclusion of the missing phar file, this hardly warrants 5.1.5 or  
even 5.1.4pl1. This will have no impact of people who have already  
downloaded and installed PHP, nor will this impact people who have  
yet to download PHP.

> PHP.net is more and more turning into Microsoft (more than 3 months to
> resolve critical security problems). I guess that comes with the
> involvement of Enterprise companies.
>

The patches for security holes are usually in within a week, if you  
want to fetch them you can do so either in a form of a PHP snapshot  
of a specific patch from CVS. To make releases every-time we get  
security fault is impractical. Like most other projects a number of  
security fixes is combined into group and when a group is  
sufficiently large a release is made. None of the bugs resolved were  
super-critical issues such as remote code execution, which would  
indeed warrant something like an emergency release just for that  
particular patch.

Ilia

---

## #23370 — Stefan Esser — 2006-05-15T15:50:56+00:00

URL: https://externals.io/message/23367#23370 · In reply to: #23369

Hey,
>
> The code in the release did not change on bit, the only change was the
> inclusion of the missing phar file, this hardly warrants 5.1.5 or even
> 5.1.4pl1. This will have no impact of people who have already
> downloaded and installed PHP, nor will this impact people who have yet
> to download PHP.
>
It will have an effect on everyone using f.e. gentoo linux or BSD port
system, because mysteriously the hash of the tarball changed and people
will get warnings about modified tarballs. It also has the effect that I
am getting emails from people asking me if PHP.net was backdoored,
because the MD5 hash changed....
And if you want to change tarballs and don't change the version number
(which is considered very bad by many people) then atleast WARN people
about the modified tarball. A simple message: tarball was missing PEAR
and was therefore rerolled is not so bad...

> The patches for security holes are usually in within a week, if you
> want to fetch them you can do so either in a form of a PHP snapshot of
> a specific patch from CVS. To make releases every-time we get security
> fault is impractical.
First the zend_hash_del() bug caused remote code execution in a bunch of
popular PHP scripts. Secondly most open source projects release security
bugfix releases. PHP.net on the other hand doesn't do this anymore.
There are no security only fixes anymore. Instead we release not
properly tested new versions of PHP that break tons of servers. (fastcgi
....)

And well... I still see no PHP 4.4.3 on PHP.net... However we still
offer the PHP 4.4.2 tarball (knowing that it has critical security
holes). So either we release a security FIX release or we kick the
tarball and declare PHP4 unsupported from now on.

Yours,
Stefan Esser

---

## #23372 — Sebastian Bergmann — 2006-05-15T16:05:53+00:00

URL: https://externals.io/message/23367#23372 · In reply to: #23369

Ilia Alshanetsky wrote:
> The code in the release did not change on bit, the only change was the
> inclusion of the missing phar file, this hardly warrants 5.1.5 or even
> 5.1.4pl1. This will have no impact of people who have already downloaded
> and installed PHP, nor will this impact people who have yet to download
> PHP.

 The checksum(s) changed, which is a problem for Gentoo Linux, for
 instance.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

---

## #23374 — Andi Gutmans — 2006-05-15T16:14:20+00:00

URL: https://externals.io/message/23367#23374 · In reply to: #23367

Stefan,

I don't see why this attack is directed at Zend people working on 
PHP, where the release process is completely a community driven 
effort (and last time I checked, no enterprise was involved in that 
process either).
I agree the release process isn't perfect yet, and it becomes 
increasingly hard as PHP grows, but your points would be better made 
if they were not directed against individual contributors but as an 
email to raise general awareness and discussion.
Ilia for one works hard and does his best (probably better than any 
release manager before him) to juggle between the various issues and 
priorities of each release.
Andi


At 06:39 AM 5/15/2006, Stefan Esser wrote:
>Hello,
>
>okay, mistakes happen everyday but it really sucks that PHP.net
>continues trying to hide mistakes.
>
>1) PHP 5.1.4 was released with a nonsense announcement claiming that
>there was only a problem with POST arrays or POST fileuploads.
>     -> In reality a paid Zend developer had destroyed the handling of
>arrays in any kind of user input in PHP 5.1.3 completely. Ironically
>after that incident another Zend man came forward and dares to say "I
>don't trust our core testers anymore"
>2) PHP 5.1.4 was lacking the PEAR installer which resulted in make
>install downloading the file from the web.
>     a) this part should be removed from the make file completlely
>because 'make install' is usually executed as root and under no
>circumstances should download a file from an insecure HTTP source.
>     b) this fact was again hidden by silently replacing the PHP 5.1.4
>tarball with a new one, after the other one was out for more than a week.
>
>PHP.net is more and more turning into Microsoft (more than 3 months to
>resolve critical security problems). I guess that comes with the
>involvement of Enterprise companies.
>
>Yours,
>Stefan Esser

---

## #23375 — Ilia Alshanetsky — 2006-05-15T16:14:56+00:00

URL: https://externals.io/message/23367#23375 · In reply to: #23370

> Hey,
> > […]
> It will have an effect on everyone using f.e. gentoo linux or BSD port
> system, because mysteriously the hash of the tarball changed and  
> people
> will get warnings about modified tarballs. It also has the effect  
> that I
> am getting emails from people asking me if PHP.net was backdoored,
> because the MD5 hash changed....
> And if you want to change tarballs and don't change the version number
> (which is considered very bad by many people) then atleast WARN people
> about the modified tarball. A simple message: tarball was missing PEAR
> and was therefore rerolled is not so bad...

I'll add that to the 5.1.4 release message on the front page, that  
was an oversight on my part.

>
> > […]
> First the zend_hash_del() bug caused remote code execution in a  
> bunch of
> popular PHP scripts. Secondly most open source projects release  
> security
> bugfix releases. PHP.net on the other hand doesn't do this anymore.
> There are no security only fixes anymore. Instead we release not
> properly tested new versions of PHP that break tons of servers.  
> (fastcgi
> ....)
>

"Tons" is a very quantitate number ;-), while fastcgi is definitely a  
used SAPI, it is no where near  the usage of the Apache sapi or even  
plain cgi. According to a basic Google Search mod_php is about 8  
times more popular then CGI/FastCGI and of the 24,000 found `phpinfo()`  
for the latter I'd wager no more then 1/2 actually use FastCGI.

> And well... I still see no PHP 4.4.3 on PHP.net... However we still
> offer the PHP 4.4.2 tarball (knowing that it has critical security
> holes). So either we release a security FIX release or we kick the
> tarball and declare PHP4 unsupported from now on.

PHP 4 is still supported, no one is suggesting that we discontinue  
it. Derick can better comment on when he plans on making the release,  
but it will definitely happen.

Ilia

---

## #23377 — Stefan Esser — 2006-05-15T16:32:25+00:00

URL: https://externals.io/message/23367#23377 · In reply to: #23374

Hello Andi,
> I don't see why this attack is directed at Zend people working on PHP,
> where the release process is completely a community driven effort (and
> last time I checked, no enterprise was involved in that process either).
Well I don't see why Zend people commit code that obviously broke a key
functionality without testing it. And then Zend people come out under
the trees and speak up that our testers are doing bad jobs. It is true
that obviously NOONE has tested the code, because otherwise it would
have been seen instantly.

> Ilia for one works hard and does his best (probably better than any
> release manager before him) to juggle between the various issues and
> priorities of each release.
Andi, I was not speaking against Ilia. I know that he does a job that
actually noone really likes todo. The problems with 5.1.x releases have
to be blamed on other parties. Maybe you can say it was his fault that
this stupid .phar was not in the archive, but the bigger fault is the
lack of a sense of basic security principles. From my point of view it
is unbelievable how someone can add a 'wget pear.php.net/bla...' to the
'make install' process. Of course this is not triggered if the .phar
file is packaged, but this fallback is insane.

And Ilia has also nothing todo with the lack of a PHP 4.4.3 release.

Yours,
Stefan Esser

---

## #23381 — Andi Gutmans — 2006-05-15T16:45:53+00:00

URL: https://externals.io/message/23367#23381 · In reply to: #23377

At 09:32 AM 5/15/2006, Stefan Esser wrote:
>Hello Andi,
> > […]
>Well I don't see why Zend people commit code that obviously broke a key
>functionality without testing it. And then Zend people come out under
>the trees and speak up that our testers are doing bad jobs. It is true
>that obviously NOONE has tested the code, because otherwise it would
>have been seen instantly.

My point was that this has nothing to do with Zend or not Zend. It's 
happened to all of us in the past (except for maybe you) where we 
have commited code that had problems. It's counter-productive to 
attack individuals and/or entities about this especially when 
everyone's working towards the same goal of contributing to PHP.

So people screw up. I prefer having the occasional screw up then less 
people helping out.

Andi

---

## #23383 — Stefan Esser — 2006-05-15T17:10:03+00:00

URL: https://externals.io/message/23367#23383 · In reply to: #23381

Hey Andi
> My point was that this has nothing to do with Zend or not Zend. 
My point is not that someone from Zend broke it, but that someone from
Zend blamed the community that THEY failed to find the problem. I
thought Zend is enough into PHP to test their own products against RC's,
too. It makes me angry that in the last months again and again people
who earn their money with PHP come and insult those who work on PHP for
free and do all the hard work.
> It's happened to all of us in the past (except for maybe you) where we
> have commited code that had problems. 
Hehe... I also commited code that cause problems in a release... Like a
very slow `unserialize()` in 4.3.??. And yes I tested it back then but
unfortunately that bug only was causing problems were large quantities
of data had to be unserialized.

> So people screw up. I prefer having the occasional screw up then less
> people helping out.
Yeah. But maybe we should setup some rules what exactly we should do
when there is a broken tarball or missing files. While it seems nice to
just repackage and silently change it (or change it with a warning), it
is considered bad practice and is especially bad for people using
distributions like Gentoo or the BSD ports system. Even if we don't
change the version number we could rename the tarball to
php-5.1.4-repack-1.tar.bz2 or something alike.

---

## #23386 — Antony Dovgal — 2006-05-15T17:33:23+00:00

URL: https://externals.io/message/23367#23386 · In reply to: #23383

> Hey Andi
> > […]
> My point is not that someone from Zend broke it, but that someone from
> Zend blamed the community that THEY failed to find the problem. I
> thought Zend is enough into PHP to test their own products against RC's,
> too. It makes me angry that in the last months again and again people
> who earn their money with PHP come and insult those who work on PHP for
> free and do all the hard work.

Oh, no.. You said it.

I get NO MONEY for testing PHP, fixing bugs, writing tests, helping users to solve their own problems @ bugs.php.net, maintaining several my own PECL modules etc. etc.
This is all my own "just for fun" job that I do in my spare time FOR FREE.

So it makes me a bit angry when someone who did nothing (except for a couple of mails to internals@) for PHP since December starts treating me and Dmitry (who's one of the most active PHP contributors) like a millionaires who earned their millions from poor PHP community.
Whether you want it or not, but we are the part of this community and yes, it was partly MY own fault that the bug has slipped in.

So please stop your trolling session and start writing new tests or at least doing something more productive than you're doing now.
Thank you.

-- 
Wbr, 
Antony Dovgal

---

## #23390 — Sebastian Bergmann — 2006-05-15T18:02:59+00:00

URL: https://externals.io/message/23367#23390 · In reply to: #23386

Antony Dovgal wrote:
> So it makes me a bit angry when someone who did nothing (except for a
> couple of mails to internals@) for PHP since December starts treating me
> and Dmitry (who's one of the most active PHP contributors) like a
> millionaires who earned their millions from poor PHP community.

 Now this is an unfair argument as Stefan cannot (for whatever reasons)
 commit his work to cvs.php.net.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

---

## #23391 — Stefan Esser — 2006-05-15T18:08:09+00:00

URL: https://externals.io/message/23367#23391 · In reply to: #23386

> So it makes me a bit angry when someone who did nothing (except for a
> couple of mails to internals@) for PHP since December starts treating
> me and Dmitry (who's one of the most active PHP contributors) like a
> millionaires who earned their millions from poor PHP community.
Tony, you have obviously no clue about my contributions to the PHP
community. Do you have any clue how many security holes I have reported
in the last months? Do you have any clue how many mails I had to write
to angry security researchers that got ignored by the rest of the PHP
Security Response Team.

Yours,
Stefan Esser

---

## #23393 — Sebastian Bergmann — 2006-05-15T18:16:17+00:00

URL: https://externals.io/message/23367#23393 · In reply to: #23390

Sebastian Bergmann wrote:
> Now this is an unfair argument as Stefan cannot (for whatever reasons)
> commit his work to cvs.php.net.

 Strike that, I was educated about this on IRC just now. My initial
 point is still valid to some degree, IMHO: just because Stefan's work
 does not go into cvs.php.net does not mean that he is not helping to
 make PHP better (more secure in his case).

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

---

## #23394 — Zeev Suraski — 2006-05-15T18:20:16+00:00

URL: https://externals.io/message/23367#23394 · In reply to: #23391

Stefan,

If anything, that was a good drill on why it's not a good idea to 
write sarcastic, negative emails to people.  Unless of course, your 
aim is to annoy them into starting a heated threads.  You've raised 
some good points in your original email, and it's a shame you diluted 
your message by implying all sorts of things about Dmitry and 
Tony.  Instead of discussing the points, we're discussing these 
pointless topics of who contributes more.  I suggest we stop here, I 
think it's absurd to question the level of contribution from any of you three.

Zeev

At 21:08 15/05/2006, Stefan Esser wrote:

> > […]
>Tony, you have obviously no clue about my contributions to the PHP
>community. Do you have any clue how many security holes I have reported
>in the last months? Do you have any clue how many mails I had to write
>to angry security researchers that got ignored by the rest of the PHP
>Security Response Team.
>
>Yours,
>Stefan Esser

---

## #23398 — Stefan Esser — 2006-05-15T18:29:43+00:00

URL: https://externals.io/message/23367#23398 · In reply to: #23394

Zeev,
> Instead of discussing the points, we're discussing these pointless
> topics of who contributes more.  I suggest we stop here, I think it's
> absurd to question the level of contribution from any of you three.
You are right. The discussion can stop here. Antony once again proved
every single word I wrote about him with his reaction.

Stefan

---

## #23401 — Marcus Boerger — 2006-05-15T18:42:32+00:00

URL: https://externals.io/message/23367#23401 · In reply to: #23377

Hello Stefan,

Monday, May 15, 2006, 6:32:25 PM, you wrote:

> Hello Andi,
> > […]
> Well I don't see why Zend people commit code that obviously broke a key
> functionality without testing it. And then Zend people come out under
> the trees and speak up that our testers are doing bad jobs. It is true
> that obviously NOONE has tested the code, because otherwise it would
> have been seen instantly.

To rephrase Andi "So people screw up. I prefer having the occasional
screw up then less people helping out." We are a community [...]
What we need is more helping hands and less comlaining notes. Actually
we are constantly working on increasing or QA efforts. And from my
point Ilia so far has done a very good job. A few minor mistakes so
far maybe.

marcus

---

## #23409 — Zeev Suraski — 2006-05-15T19:24:04+00:00

URL: https://externals.io/message/23367#23409 · In reply to: #23398

At 21:29 15/05/2006, Stefan Esser wrote:
>Zeev,
> > […]
>You are right. The discussion can stop here. Antony once again proved
>every single word I wrote about him with his reaction.

Stefan,

You've got to be kidding.  Just stop.

Zeev

---

## #23438 — Lukas Smith — 2006-05-16T00:04:05+00:00

URL: https://externals.io/message/23367#23438 · In reply to: #23401

Marcus Boerger wrote:

> To rephrase Andi "So people screw up. I prefer having the occasional
> screw up then less people helping out." We are a community [...]
> What we need is more helping hands and less comlaining notes. Actually
> we are constantly working on increasing or QA efforts. And from my
> point Ilia so far has done a very good job. A few minor mistakes so
> far maybe.

That being said .. if there are any additions people have to give better 
guidelines for RM's please drop a comment at the following address:
http://oss.backendmedia.com/ReleaseChecklist

regards,
Lukas

---

## #23444 — Phil Driscoll — 2006-05-16T07:07:13+00:00

URL: https://externals.io/message/23367#23444 · In reply to: #23438

> That being said .. if there are any additions people have to give better
> guidelines for RM's please drop a comment at the following address:
> http://oss.backendmedia.com/ReleaseChecklist

I've just added the following comment, which addresses part of the problem:
--------------------
Somewhere between the RC and the release, the release manager should
receive email confirmation from a number of volunteers that the RC has
been tested not only with 'make test', but on real world applications such
as the volunteers' own code and high profile applications such as
phpMyAdmin, SquirrelMail and so on.

The RC should not become a release until such confirmation is received.
--------------------

I hereby volunteer to do my code, phpMyAdmin and SquirrelMail for php5 RCs.

Clearly, for this to have maximum impact we need to cover as many 
applications, platforms and SAPIs as possible.
-- 
Phil Driscoll

---

## #23445 — Jasper Bryant-Greene — 2006-05-16T07:12:38+00:00

URL: https://externals.io/message/23367#23445 · In reply to: #23444

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Phil Driscoll wrote:
> 
> > […]
> 
> I've just added the following comment, which addresses part of the problem:
> --------------------
> Somewhere between the RC and the release, the release manager should
> receive email confirmation from a number of volunteers that the RC has
> been tested not only with 'make test', but on real world applications such
> as the volunteers' own code and high profile applications such as
> phpMyAdmin, SquirrelMail and so on.
> 
> The RC should not become a release until such confirmation is received.
> --------------------
> 
> I hereby volunteer to do my code, phpMyAdmin and SquirrelMail for php5 RCs.
> 
> Clearly, for this to have maximum impact we need to cover as many 
> applications, platforms and SAPIs as possible.

I like this idea. I can volunteer to do reasonably thorough testing
(both a 'make test' and real-world app testing) of 5.x releases on a
very large OO application running on Linux / Apache 2.2. It's not an
open-source app, but that doesn't mean I can't help with testing, does it?

- --
Jasper Bryant-Greene
General Manager
Album Limited

http://www.album.co.nz/     0800 4 ALBUM
jasper@album.co.nz          021 708 334
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFEaXtmFfAeHhDzT4gRA55iAKCVTuNMLR4l+aCmp1D86FoNQX12qwCffAgW
HaAcyfx6XSZlISShJVveg8o=
=9zMN
-----END PGP SIGNATURE

---

## #23446 — Marcus Boerger — 2006-05-16T07:58:57+00:00

URL: https://externals.io/message/23367#23446 · In reply to: #23444

Hello Phil,

Tuesday, May 16, 2006, 9:07:13 AM, you wrote:

> 
> > […]

> I've just added the following comment, which addresses part of the problem:
> --------------------
> Somewhere between the RC and the release, the release manager should
> receive email confirmation from a number of volunteers that the RC has
> been tested not only with 'make test', but on real world applications such
> as the volunteers' own code and high profile applications such as
> phpMyAdmin, SquirrelMail and so on.

> The RC should not become a release until such confirmation is received.

Maybe we should even just repack the RC with a single change allowed, the
vrsion bump.


Best regards,
 Marcus

---

## #23452 — Ilia Alshanetsky — 2006-05-16T12:51:37+00:00

URL: https://externals.io/message/23367#23452 · In reply to: #23444

For every RC we already send an e-mail to about 12 projects asking  
them to test their code against the release and let us know of any  
issues that come up. If you want to be part of this group ask Lukas  
to add you to the wiki page that can be found here: http:// 
oss.backendmedia.com/PhP5yz




> 
> > […]
>
> I've just added the following comment, which addresses part of the  
> problem:
> --------------------
> Somewhere between the RC and the release, the release manager should
> receive email confirmation from a number of volunteers that the RC has
> been tested not only with 'make test', but on real world  
> applications such
> as the volunteers' own code and high profile applications such as
> phpMyAdmin, SquirrelMail and so on.
>
> The RC should not become a release until such confirmation is  
> received.
> --------------------
>
> I hereby volunteer to do my code, phpMyAdmin and SquirrelMail for  
> php5 RCs.
>
> Clearly, for this to have maximum impact we need to cover as many
> applications, platforms and SAPIs as possible.
> -- 
> Phil Driscoll
>
> -- 
> 
> 
>
>

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

---

## #23453 — Phil Driscoll — 2006-05-16T12:59:29+00:00

URL: https://externals.io/message/23367#23453 · In reply to: #23452

> For every RC we already send an e-mail to about 12 projects asking
> them to test their code against the release and let us know of any
> issues that come up. If you want to be part of this group ask Lukas
> to add you to the wiki page that can be found here: http://
> oss.backendmedia.com/PhP5yz
I already get these via the php-qa list, however the improvement I want to 
make to the process is to stop an RC becoming a release until positive 
responses have been received from at least a reasonable proportion of a list 
of people who have committed to do some testing.
-- 
Phil Driscoll

---

Next page: https://externals.io/message/23367.md?page=2