hi,
On Mon, Jul 7, 2008 at 4:35 AM, Steph Fox [EMAIL PROTECTED] wrote:
Hi all,
I cvs remove'd this file and then realized it was retained for .dsp
compatibility. (It's not used in the cl build system.)
Is anyone still using the old build system? Or can we ditch the old Windows
project
On Mon, Jul 7, 2008 at 3:23 AM, Steph Fox [EMAIL PROTECTED] wrote:
sfoxMon Jul 7 01:23:56 2008 UTC
Modified files: (Branch: PHP_5_3)
/php-src/win32/buildconfig.w32 confutils.js
Log:
- Fix up some bits and pieces.
For examples? Log message helps to see
Hello!
As it's about a month until the end of PHP 4, it's time to make the last
release. There have been a few important fixes, which need to be part of
a release. If you have anything else, please let me know so we can
integrate it in the release as well. I'm planning to make a release
I like the idea, and I think we don't need --enable-signals options.
BTW I'm not sure about committing it into 5.3. It's a question to RM(s).
Thanks. Dmitry.
Lucas Nealan wrote:
Hi Internals,
I am proposing the following RFC to improve signal handling in the Zend
Engine:
On Mon, Jul 7, 2008 at 09:09, Derick Rethans [EMAIL PROTECTED] wrote:
Hello!
As it's about a month until the end of PHP 4, it's time to make the last
release. There have been a few important fixes, which need to be part of
a release.
Out of curiosity, which ones and why aren't they in the
Hannes Magnusson wrote:
On Mon, Jul 7, 2008 at 09:09, Derick Rethans [EMAIL PROTECTED] wrote:
Hello!
As it's about a month until the end of PHP 4, it's time to make the last
release. There have been a few important fixes, which need to be part of
a release.
Out of curiosity, which ones and
On Mon, 7 Jul 2008, Jani Taskinen wrote:
Hannes Magnusson wrote:
On Mon, Jul 7, 2008 at 09:09, Derick Rethans [EMAIL PROTECTED] wrote:
Hello!
As it's about a month until the end of PHP 4, it's time to make the last
release. There have been a few important fixes, which need to be
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (64 total -- which includes 26 feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
PHP 4 end of life announcement:
After 2007-12-31 there will be no more releases of PHP 4.4.
We will continue to make critical security fixes available
on a case-by-case basis until 2008-08-08.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi Pierre,
- Fix up some bits and pieces.
For examples? Log message helps to see what has been changed, please be
verbose.
Literally 'bits and pieces'. The duplicate function we discussed, ws, moving
the MS versioning stuff to somewhere it could be used in config.w32.h. (Not
moving it
On Mon, Jul 7, 2008 at 2:33 PM, Steph Fox [EMAIL PROTECTED] wrote:
Hi Pierre,
- Fix up some bits and pieces.
For examples? Log message helps to see what has been changed, please be
verbose.
Literally 'bits and pieces'. The duplicate function we discussed, ws, moving
the MS versioning
Hi Pierre,
I'm about to commit some other changes, do you have any other pending
commits?
Not in this area. I'll concentrate on killing the .dsp files off - I tested
now and they don't even work any more under VC6.
One change I will apply is to put the useful functions and data in
Hello Derick,
Janusz is damn right here. Make the patches available but do not make it
easy for people to stick to 4 please. Instead, stick to th eplan.
marcus
Monday, July 7, 2008, 1:15:19 PM, you wrote:
PHP 4 end of life announcement:
After 2007-12-31 there will be no more releases of
On Mon, Jul 7, 2008 at 3:03 PM, Steph Fox [EMAIL PROTECTED] wrote:
One change I will apply is to put the useful functions and data in
confutils and not in a specific config.w32. confutils is the common
trunc and is run before any other config.w32 code.
Please test this first. I'm talking
On Mon, Jul 7, 2008 at 3:02 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Derick,
Janusz is damn right here. Make the patches available but do not make it
easy for people to stick to 4 please. Instead, stick to th eplan.
I tend to agree here, a new release may contradict the purpose of
this file is generated automatically on each time you run configure.
It is fine to keep the config.w32.h.in as dummy template (it is not
used), so we have a file in cvs with all possible values, just like a
autoconf's configurefile.
Ah no, you've misunderstood it. The config.w32.h.in file is
On Mon, Jul 7, 2008 at 3:18 PM, Steph Fox [EMAIL PROTECTED] wrote:
this file is generated automatically on each time you run configure.
It is fine to keep the config.w32.h.in as dummy template (it is not
used), so we have a file in cvs with all possible values, just like a
autoconf's
I will update the js again and add some comments to avoid confusions
in the future (HEAD and 5.3, please also apply any of your commits to
both branches).
Eh, just the one leetle old laptop with not much space or memory. One day
5.3, next day HEAD. I don't mind doing my own MFB, it's just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Janusz Lewandowski schrieb:
PHP 4 end of life announcement:
After 2007-12-31 there will be no more releases of PHP 4.4.
We will continue to make critical security fixes available
on a case-by-case basis until 2008-08-08.
Considering the fact that
Hi,
I do not have karma, but I still think you guys missed one point in
the entire thing.
The end of life cycle of PHP4 is 08-08-08, so people expect one last
release in this day as the last release.
Some of you are telling that release something now contradicts your
master plan, but you missed
2008/7/7 Guilherme Blanco [EMAIL PROTECTED]:
The end of life cycle of PHP4 is 08-08-08, so people expect one last
release in this day as the last release.
Some of you are telling that release something now contradicts your
master plan, but you missed something.
If you don't release something
On Mon, Jul 7, 2008 at 10:39 AM, Janusz Lewandowski [EMAIL PROTECTED] wrote:
2008/7/7 Guilherme Blanco [EMAIL PROTECTED]:
The end of life cycle of PHP4 is 08-08-08, so people expect one last
release in this day as the last release.
Some of you are telling that release something now contradicts
Hi Stefan,
Considering the fact that PHP 4.4.8 is known to have several public
security problems that where only fixed in PHP 5, releasing PHP 4.4.9
as last final version is the right thing todo.
Fixing any major security hole in 4.4 at this point would put an abrupt end
to this argument ;)
On Mon, 7 Jul 2008, Marcus Boerger wrote:
Janusz is damn right here. Make the patches available but do not
make it easy for people to stick to 4 please. Instead, stick to th
eplan.
We do, there are security fixes - we make a release.
regards,
Derick
--
Derick Rethans
Hartmut Holzgraefe wrote:
i've started looking into the patch yesterday, there are still some
small issues with it though ... i'll provide you with more detailed
comments later today or early tomorrow ...
open questions:
- should the functions return an error if using the specified oid
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2008 7:22 AM
To: Marcus Boerger
Cc: PHP Internals; Janusz Lewandowski
Subject: Re: [PHP-DEV] PHP 4.4.9
On Mon, 7 Jul 2008, Marcus Boerger wrote:
Janusz is damn right here. Make the
Hello,
On Mon, Jul 7, 2008 at 9:29 AM, Andi Gutmans [EMAIL PROTECTED] wrote:
On Mon, 7 Jul 2008, Marcus Boerger wrote:
Janusz is damn right here. Make the patches available but do not
make it easy for people to stick to 4 please. Instead, stick to th
eplan.
We do, there are
On Mon, Jul 7, 2008 at 10:29 AM, Andi Gutmans [EMAIL PROTECTED] wrote:
I'm with Derick here. We should push out new releases when there are security
issues
As am I. The EOL announcement itself justifies the release:
We will continue to make critical security fixes available on a
Hello Stefan,
this can be continued forever. Say we release 4.4.9, then sooner or
later people will find another security whole, so we do another release.
And another release and in the year 2134 our childrens children will
release 4.4.4363
marcus :-)
Monday, July 7, 2008, 3:28:54 PM, you
Hello Derick,
how about this. We edit php_config.h to be version 4.4.8pl1. Then
provide a patch for download. All reasonable distributions will pick up
that patch anyway. But at least we didn't do a release as we promised, we
wouldn't.
marcus
Monday, July 7, 2008, 9:09:51 AM, you wrote:
On Mon, 7 Jul 2008, Marcus Boerger wrote:
this can be continued forever. Say we release 4.4.9, then sooner or
later people will find another security whole, so we do another release.
And another release and in the year 2134 our childrens children will
release 4.4.4363
Uh, no. The last date
Derick Rethans wrote:
On Mon, 7 Jul 2008, Marcus Boerger wrote:
how about this. We edit php_config.h to be version 4.4.8pl1. Then
provide a patch for download. All reasonable distributions will pick up
that patch anyway. But at least we didn't do a release as we promised, we
wouldn't.
Uh,
The purpose of the account is to commit PHP tests into the code base. Please
see Lukas Smith and Zoe Slattery on the QA team for recommendation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans wrote:
On Mon, 7 Jul 2008, Marcus Boerger wrote:
how about this. We edit php_config.h to be version 4.4.8pl1. Then
provide a patch for download. All reasonable distributions will pick up
that patch anyway. But at least we didn't do a release as we promised, we
wouldn't.
Uh,
Hi Dmitry,
I like the idea, and I think we don't need --enable-signals options.
I would like to have this enabled by default and this would be very easy to
change. We¹ve been running in production for a few months and we use the
option to make it easier to disable at build time for testing.
Hi!
I am proposing the following RFC to improve signal handling in the Zend
Engine:
http://wiki.php.net/rfc/zendsignals
Looks good. If ti works, I don't think we need two signal models - new
one would be OK. I'm not sure what happens with win32 though.
--
Stanislav Malyshev, Zend Software
Stanislav Malyshev wrote:
Hi!
I am proposing the following RFC to improve signal handling in the Zend
Engine:
http://wiki.php.net/rfc/zendsignals
Looks good. If ti works, I don't think we need two signal models - new
one would be OK. I'm not sure what happens with win32 though.
Note that
Hi Stas,
Looks good. If ti works, I don't think we need two signal models - new
one would be OK. I'm not sure what happens with win32 though.
This has not been tested on windows but it `should` be unaffacted. If built
with ZEND_MAINTAINER_ZTS or if sigaction() is not detected then ZEND_SIGNALS
Hi!
This fixes the logic problem, and re-introduces the performance slowdown
for internal classes. FORTUNATELY there is a simple solution to this,
which is to use all global classes:
The thing is since it'd work without use, most users would do it that
way and have horrible code. But if
Hartmut Holzgraefe wrote:
i've started looking into the patch yesterday, there are still some
small issues with it though ... i'll provide you with more detailed
comments later today or early tomorrow ...
open questions:
- should the functions return an error if using the
Wow, any idea how the PHP list thought this was me that wanted to
unsubscribe?
--
Brian Moon
Senior Web Engineer
--
When you care enough to spend the very least.
http://dealnews.com/
---BeginMessage---
Hi! This is the ezmlm program. I'm managing the
41 matches
Mail list logo
