On Dec 1, 2010, at 5:16 PM, Johannes Schlüter wrote:
On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote:
On 2010-12-01, Pierre Joye pierre@gmail.com wrote:
hi,
I think we have enough feedback about this topic. We will come back
with a detailed proposal explaining how it could
+1 for PHP 7.0. :)
Stuff like this accumulating in trunk kinda makes it more and more
something else than minor release..
--Jani
27.11.2010 19:40, Johannes Schlüter kirjoitti:
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier
Who says it has to be 5.4? People seem to be a bit fixated on the version
there.
Major BC breaks just means the version released from trunk is 6.0. And it's
just a number. Big number, but still just a number.
Merging (by and or by magic :) features into branch created from 5.3 just
sounds
the language is perceived to some degree).
My 2c.
Zeev
-Original Message- From: Johannes Schlüter
[mailto:johan...@schlueters.de] Sent: Thursday, November 25, 2010
7:55 PM To: Andi Gutmans Cc: Jani Taskinen; da...@php.net; PHP
Internals Subject: RE: [PHP-DEV] Re: Hold off 5.4
On Thu, 2010-11
On Nov 19, 2010, at 11:38 AM, Johannes Schlüter wrote:
On Fri, 2010-11-19 at 10:30 +0100, Johannes Schlüter wrote:
And get rid of those ancient Changelog* files as well. :)
I proposed this in the past.
See http://www.mail-archive.com/internals@lists.php.net/msg46669.html
If nobody
On Nov 18, 2010, at 12:12 PM, Johannes Schlüter wrote:
Yes. We have to get rid of them! I was +1 for the old PHP 6 as that
breaks so much stuff that it is nowhere a drop in replacement. And as
such I'm happy to drop it in any release breaking lots of applications.
I'm not happy about dropping
On Nov 18, 2010, at 12:41 PM, Patrick ALLAERT wrote:
Disabling it by default is the first mandatory step, [done] in PHP
5.3, magic_quotes_gpc has been turned off by default at the same time
as providing a -development and -production version of the php.ini
file.
AFAICT magic_quotes_gpc is
19.11.2010 0:39, Johannes Schlüter kirjoitti:
Hi,
after the 5.3.3 release I was approached with the request to restructure
the NEWS file -- for instance by grouping entries by extension -- so
users can identify whether there are bug fixes relevant for them etc.
Something that I did in trunk
13.11.2010 23:24, Matti Bickel kirjoitti:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/13/2010 08:50 PM, Stanley Sufficool wrote:
2010/11/13 Jérôme Loyetjer...@loyet.net:
Le 12 novembre 2010 23:57, Jani Taskinenjani.taski...@iki.fi a écrit :
I updated the patch:
and no
binaries have been selected, we should trigger an error message. The
configture is terminating normaly et make does nothing (normal).
++ Jerome
--Jani
12.11.2010 2:40, Jani Taskinen kirjoitti:
I'm working on an improvement on how all binaries are build thus
enabling building all such in one
11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti:
Hi Jérôme
2010/11/11 Jérôme Loyetjer...@loyet.net:
If this is a normal behaviour, we should add an error at configure
telling that only one SAPI is supported at once.
It not, we should correct it.
Did I miss something ?
On Windows we have no
I'm working on an improvement on how all binaries are build thus
enabling building all such in one go if one wants to. I already added a
check for multiple sapi _modules_ being build, it will error out.
Stay tuned, I'll post the patch once I've tested it a bit.
--Jani
12.11.2010 0:03,
And here's the patch:
http://pecl.php.net/~jani/patches/multi-sapi.patch
Note: It's not quite finished, the 'make install' might not work.. ;)
--Jani
12.11.2010 2:40, Jani Taskinen kirjoitti:
I'm working on an improvement on how all binaries are build thus
enabling building all
24.3.2010 12:54, Lukas Kahwe Smith wrote:
Hey,
Could one of you write up a short RFC on this patch? Just some details about
the bugs fixed, known BC breaks and (undocumented) edge case changes. This
would be helpful for anyone wanting to review their code and testing as well
as
24.3.2010 12:02, Lukas Kahwe Smith wrote:
On 23.03.2010, at 23:04, Andi Gutmans wrote:
What about defining a release manager for the next release? I think that
is an important aspect of moving things forward. I also thought the dual
RM in PHP 5.3 worked quite well although it is not
Having tests in multiple branches is PITA. Hasn't anyone considered that
the best way would be to move all tests into their own repository
(directory..whatever :) in SVN..? Considering they are supposed to be
used for testing against regressions and BC breaks, they should always
be runnable
On 03/12/2010 12:29 PM, Hannes Magnusson wrote:
On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taski...@iki.fi wrote:
Having tests in multiple branches is PITA. Hasn't anyone considered that the
best way would be to move all tests into their own repository
(directory..whatever :) in SVN..?
On 03/12/2010 01:40 PM, Keryx Web wrote:
If the next update is quite big and breaks backwards compatibility in
some ways, go directly to 7.
Yes, I hope others get over the version-fobia too. :)
We can't call the new (soon to be?) trunk PHP 6. Calling it 5.4 is not
working either considering
On 03/11/2010 11:41 PM, Christopher Jones wrote:
Ilia Alshanetsky wrote:
+1. I think we need we need to make HEAD a common use branch where
most of the developers trees are at and current HEAD iteration is just
not it.
I'm +1. Jani's recent 5.3 changes should be reverted, PHP_5_4
On 03/12/2010 01:48 PM, Ulf Wendel wrote:
Jani Taskinen schrieb:
Having tests in multiple branches is PITA. Hasn't anyone considered
that the best way would be to move all tests into their own repository
(directory..whatever :) in SVN..? Considering they are supposed to be
used for testing
Is that new implementation in trunk already? Is it (or will it be)
backwards compatible with the current one?
--Jani
On 03/12/2010 06:38 PM, Moriyoshi Koizumi wrote:
I'd love to see my brand-new mbstring implementation in the release.
Dropping mbstring completely won't be any good because
On 03/12/2010 08:08 PM, Stanislav Malyshev wrote:
Hi!
Having tests in multiple branches is PITA. Hasn't anyone considered that
the best way would be to move all tests into their own repository
(directory..whatever :) in SVN..? Considering they are supposed to be
Yes, but: some tests are
On 03/12/2010 04:15 PM, Ulf Wendel wrote:
For a transition period there's likely to be more work and the number of
test failures is likely to go up. That is nothing to really worry about
as long as you manage to educate users that it is not a quality defect
of PHP as such but a temporary matter
13.3.2010 0:18, Stanislav Malyshev wrote:
Hi!
There are going to be some technical challenges. Some (maybe a lot) of
test
will need updates or rewriting. run-tests.php may need more improvements
than what is already planned. Knowing this, I would still rather update
run-tests.php and fix the
On 03/11/2010 12:50 PM, Johannes Schlüter wrote:
On Thu, 2010-03-11 at 10:24 +, Jani Taskinen wrote:
jani Thu, 11 Mar 2010 10:24:29
+
Revision: http://svn.php.net/viewvc?view=revisionrevision=296062
Log:
MFH: Improved / fixed output buffering
On 03/11/2010 02:38 PM, Sebastian Bergmann wrote:
Lukas Kahwe Smith wrote:
php6 not moving forward is the root cause there
So lets just close the PHP 5.2 branch and open the PHP 5.4 branch.
The focus of PHP 5.4 could be the new output layer and traits (one can
dream, right?).
I'm not
On 03/11/2010 04:41 PM, Lukas Kahwe Smith wrote:
@jani: committing to a stable branch because you are getting a new laptop is
not really a convincing argument. :)
Losing the one with the changes in it is. Doing patches will only cause
endless headaches. Please move on, nothing to see here,
On 03/11/2010 06:21 PM, Scott MacVicar wrote:
On Mar 11, 2010, at 10:22 AM, Jani Taskinen wrote:
On 03/11/2010 04:41 PM, Lukas Kahwe Smith wrote:
@jani: committing to a stable branch because you are getting a new laptop is
not really a convincing argument. :)
Losing the one
11.3.2010 19:22, Rasmus Lerdorf wrote:
So I think Lukas and others are right, let's move the PHP 6 trunk to a
branch since we are still going to need a bunch of code from it and move
development to trunk and start exploring lighter and more approachable
ways to attack Unicode. We have a few
11.3.2010 19:54, Johannes Schlüter wrote:
On Thu, 2010-03-11 at 18:46 +0100, Lukas Kahwe Smith wrote:
+1 for moving trunk to a branch and moving 5.3 to trunk.
not moving 5.3 to trunk but a 5.3 copy (branched of), 5.3 should be
stable stuff (fixes) only. Guess you meant to say that, but better
FYI: I installed the new bug tracker to ez1.php.net for easier
testing. Feel free to test it and comment to this thread. If the DNS has
not propagated yet, just add this to your hosts file:
128.39.198.38 bugs-beta.php.net
Keep in mind it's NOT totally new, it's simply been cleaned up and
22.2.2010 17:28, Richard Quadling wrote:
A couple of low level things
Nitpicking, are we? :D
1 - Can/should the PHP Versions include release candidates?
Yes, they're outdated. This is one part that should be automated/centralized,
it's enough PITA for the RMs already to remember all the
22.2.2010 19:15, Johannes Schlüter wrote:
- Patches / file attachements
I like the idea of calling it patch so users won't immediatly upload
large big applications. Is there a size limit?
No limits apart from what is set in either httpd.conf or php.ini, also, they
need to be text
I've used APC + custom session handler for ages without any problems.
And couldn't this be fixed without such nasty hooks..?
--Jani
On 02/19/2010 05:54 PM, Christian Seiler wrote:
Hello,
[CC to pecl-dev since this is APC-related.]
I have been investigating a problem occuring when using APC
Instead of adding yet-another feature, how about fixing the bugs in the
existing ones first? f.e. there is open bug related to closures, fixing
that might be good idea before adding yet another way to abuse them:
http://bugs.php.net/50230
And in total there are 33 scripting engine
On 01/19/2010 09:29 AM, Eddie Drapkin wrote:
On Tue, Jan 19, 2010 at 2:14 AM, Alexey Zakhlestinindey...@gmail.com wrote:
Would be nice if something like this worked too:
(new Class())-method();
I was just looking at some Java code and thinking, man I wish PHP did this
Funny, I was
On 01/17/2010 05:19 AM, Raphael Geissert wrote:
Jani Taskinen wrote:
16.1.2010 20:10, Raphael Geissert wrote:
Some of the other patches include:
libdb_is_-ldb
Why? Potentially breaks things when you assume db/ being correct place..
Do you have an example of any actual case?
Do you have
16.1.2010 20:10, Raphael Geissert wrote:
Some of the other patches include:
libdb_is_-ldb
Why? Potentially breaks things when you assume db/ being correct place..
115-autoconf_ftbfs.patch
Hell no. You're breaking the configure again with this crap. I already reverted
the idiocy once,
17.1.2010 0:29, Alexey Zakhlestin wrote:
On 17.01.2010, at 1:05, Gwynne Raskind wrote:
On Jan 16, 2010, at 4:18 PM, Jani Taskinen wrote:
115-autoconf_ftbfs.patch
Hell no. You're breaking the configure again with this crap. I already reverted
the idiocy once, don't even think about doing
On 01/12/2010 10:48 PM, Raphael Geissert wrote:
Hello,
At Debian we are planning to include PHP 5.3 in Squeeze, the next stable
release. As such, I would like to know for example when we could expect
5.3.2 and 5.3.3 to be released.
Wouldn't we all. Haven't seen any merges to the release
On 12/14/2009 10:16 PM, Jérôme Loyet wrote:
Hi tony,
There is several things in this patch:
1- makes log message about pool concistent. I set it to [pool %s]
message. Before there where different variants:
pool %s,
foo (pool %s) bar
[pool %s]
[%s]
2- corrects some log messages which were not
On 12/15/2009 11:14 AM, Antony Dovgal wrote:
On 15.12.2009 12:04, Jani Taskinen wrote:
3- Some log level have been switched from NOTICE to DEBUG, so that the
log_file in normal operation would not be a nightmare to read (with a
lot of anoying and useless messages for end users)
Wouldn't
On 12/09/2009 08:37 PM, Sara Golemon wrote:
Now, I'll take some blame here for not being involved over the past
couple years and having not noticed this inanity sooner, but could
someone explain this cluster-f?
It's also bad thing to abandon code like some people tend to do.
And to ignore bug
Derick Rethans wrote:
On Mon, 7 Dec 2009, Ilia Alshanetsky wrote:
While the separate branch release for 5.3.1 was a worthwhile
experiment, I think it creates too much opportunity for missed patches
and quite frankly makes the whole release process confusing and
complicated. My personal
1. Why are you constantly not merging stuff to HEAD?
2. Isn't this related to bug #50231 and why are you not using the proper commit
message then? Hint: - Fixed bug..
It's getting quite annoying that some people (Rasmus included) tend to ignore
that we have a development branch (HEAD, trunk)
Rasmus Lerdorf wrote:
Jani Taskinen wrote:
1. Why are you constantly not merging stuff to HEAD?
2. Isn't this related to bug #50231 and why are you not using the proper
commit message then? Hint: - Fixed bug..
It's getting quite annoying that some people (Rasmus included) tend to
ignore
Gwynne Raskind wrote:
Some while ago, I committed a patch to trunk which adds the shell_bypass option to proc_open()
on UNIX. I'd like to backport that patch to 5.3.2, along with posix_pipe(), which helps quite a
bit in using it. The patch can be found at http://pastebin.ca/raw/1691644. It's
It works fine as soon as I find the typo Rasmus has done with his fixes
for autoconf 2.13..
--Jani
On 11/27/2009 10:56 AM, Arvind Srinivasan wrote:
There was some discussion on the version (2.13 vs newer) of autoconf
to use for trunk but I'm not sure whether there was any consensus.
It
Make that me. It's either my upgrade of libtool or combined changes by
me and Rasmus. And it affects ALL branches.. :(
I'm investigating this bug atm, stay tuned.
--Jani
On 11/27/2009 11:26 AM, Jani Taskinen wrote:
It works fine as soon as I find the typo Rasmus has done with his fixes
This is caused by the divert() patch Rasmus committed. Nice work.
I'll try figure out how to do it properly.
--Jani
On 11/27/2009 01:08 PM, Jani Taskinen wrote:
Make that me. It's either my upgrade of libtool or combined changes by
me and Rasmus. And it affects ALL branches.. :(
I'm
On 11/27/2009 02:30 PM, Rasmus Lerdorf wrote:
Jani Taskinen wrote:
This is caused by the divert() patch Rasmus committed. Nice work.
I'll try figure out how to do it properly.
Getting rid of just the diverts in ext/standard/config.m4 fixes this for
me. There is still an unrelated libtool
-patch code for
5.2.12? The other option is to generate the build on a machine with the later
autoconf, 2.59 seems to work fine.
On 2009-11-27, at 7:30 AM, Rasmus Lerdorf wrote:
Jani Taskinen wrote:
This is caused by the divert() patch Rasmus committed. Nice work.
I'll try figure out how to do
Alexey Zakhlestin wrote:
On 25.11.2009, at 13:43, Antony Dovgal wrote:
On 25.11.2009 13:36, Alexey Zakhlestin wrote:
Wouldn't following recommendations printed in warnings help?
Sure, but only for newer autoconf versions.
Which means we would break autoconf 2.13 if we follow them.
Is that
Sebastian Bergmann wrote:
Rasmus Lerdorf wrote:
rasmus Wed, 25 Nov 2009 01:30:06 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=291283
Log:
Someone strap down Jani and give him a sedative please.
This makes our toolchain work with the latest
Hi Johannes,
You did forget something: merging back the NEWS stuff to PHP_5_3/NEWS which has
this note:
?? ??? 2009, PHP 5.3.1
# Will be merged in from branches/PHP_5_3_1 once released
# Pleas add stuff under 5.3.2
The next release, can we do it like Ilia does them? The way this process was
On 10/21/2009 01:10 AM, Nick Fortenberry wrote:
Hey everyone,
Jake Levitt and I created this patch which adds the option to set a message's
INTERNALDATE when appending it to a mail server using imap. Any chance we can
get this included into the php 5.3 and 6 development branches? The diff
1. Top-posting is considered evil.
2. Look harder, timelib_* has several functions for this, be creative..
3. Tabs instead of spaces, NO C++ comments!
--Jani
On 10/21/2009 06:37 PM, Nick Fortenberry wrote:
Hey Jani,
We looked through the date library but it doesn't look like there are any
Matthew Fonda wrote:
Hi All,
I came across a situation where I had to make the first character of an
arrays keys uppercase, and found the array_change_key_case function, but
noticed it only supported CASE_UPPER and CASE_LOWER. Attached is a patch
to also add support for CASE_LCFIRST and
This is the current patch for bug #27792:
http://www.php.net/~wez/lfs.diff
--Jani
On 09/13/2009 01:20 PM, X Ryl wrote:
The patch in 27792 doesn't work, but the one in 48886 does (from my own
tests)
2009/9/13 Laurent Léonardlaur...@open-minds.org
Hi,
What about that bug ?
On 09/10/2009 04:46 PM, Tony Marston wrote:
You are missing the point. I'm not trying to set the encoding for any HTML
output as that is handled differently. What I am concerned about is the
func_overload option which, ever since PHP 4.2.0, we have been able to turn
on or off using an htaccess
On 09/09/2009 03:01 AM, Rasmus Lerdorf wrote:
This has been discussed before. See:
http://news.php.net/php.internals/44476
http://news.php.net/php.internals/44480
http://news.php.net/php.internals/44484
http://news.php.net/php.internals/44485
Basically it comes down to figuring out whether to
On 09/09/2009 08:55 AM, sean finney wrote:
On Wed, Sep 09, 2009 at 03:42:44AM +0100, dreamcat four wrote:
Not sure about bundling libevent though - does it have to be bundled?
Don't know. Libevent is frozen in there and a couple of files were
modified with references back into the fpm headers.
On 09/09/2009 10:53 AM, Stanislav Malyshev wrote:
As separate SAPI, wouldn't it duplicate a LOT of code, basically for
nothing? I'd rather see the good parts of this merged into the
one-and-only sapi/cgi/ code instead of creating yet another SAPI
nobody maintains for real.
If the code will be
On 09/07/2009 09:25 AM, Dmitry Stogov wrote:
Hi,
I'm wondered why the shebang line support was removed from scanner.
Because it didn't make any sense for other SAPIs. You could ask Ilia
more about it:
-
r273178 | iliaa
It's very legit to use with CGI since you might not be able to run PHP any other
way. So this is definately a bug, CGI should handle it the same as CLI.
The bug report clearly explains it too:
http://bugs.php.net/bug.php?id=49182
--Jani
Andi Gutmans wrote:
Shebang is for command line
You obviously don't understand at all what this is used for.
Consider the case where you can't change webserver's configs.
Or that you want to quickly test different PHP versions.
What would be easier than simply switching the version in the shebang line?
Quite legitimate and useful to me. And
Pierre Joye wrote:
On Sat, Sep 5, 2009 at 2:48 PM, Jani Taskinenjani.taski...@sci.fi wrote:
You obviously don't understand at all what this is used for.
Consider the case where you can't change webserver's configs.
Or that you want to quickly test different PHP versions.
What would be easier
Marco Tabini wrote:
It would be really nice if everyone could consider that the other do
understand what is being discussed but actually disagree. The question
was actually: is it worth the effort? Who is seriously using CGI (not
meaning fastcgi) with php these days?
On shared hosts, CGI is
Errors output from MINIT can not and will not ever have any other
timezone than what is the system's timezone.
If you're reporting a bug, please do it at http://bugs.php.net/.
Anyways the code in sqlsrv is pretty horrible. I'd cleanup that mess
first. Unless of course you can reproduce same
On 08/29/2009 05:33 PM, Johannes Schlüter wrote:
Hi,
I thought I sent the warning out on thursday but can't find it in my
internals folder therefore the notice:
We certainly should get 5.3.1 rolling and therefore I'm planning RC1
on Tuesday evening European time
I'm not t used to
On 08/31/2009 12:06 AM, Pierre Joye wrote:
Hi,
While trying to fix some tests, I found that display_startup_errors is
ignored by some startup errors like deprecated ini settings. Using:
php -d display_startup_errors=0 -d safe_mode=1 foo.php
See also bug #49362
On 08/25/2009 12:42 AM, Stanislav Malyshev wrote:
Hi!
Quite boring to read this thread where two persons argue about
something abstract. Stas, can you give a real life example where your
patch is necessary..?
Any code where you either use @ or error_reporting which is not -1 would
benefit
On 08/25/2009 10:35 AM, Stanislav Malyshev wrote:
Hi!
Just wondering why nobody hasn't suggested the obvious (?) alternative
yet: Why not fix error_reporting to work like one expects. As in: If
an error level isn't in it, then nothing happens. Adding an extra
option to do that seems a bit
Daniel Convissor wrote:
Hello Jani:
On Tue, Aug 25, 2009 at 11:11:19AM +0300, Jani Taskinen wrote:
On 08/25/2009 10:35 AM, Stanislav Malyshev wrote:
Because it would break other funcions (namely, $php_errormsg, error
handlers, etc.) which may be used by some.
Well, not necessarily. How
Quite boring to read this thread where two persons argue about something
abstract. Stas, can you give a real life example where your patch is necessary..?
--Jani
Stanislav Malyshev wrote:
Hi!
Unless your code is ridden or if you prefer filled with @ and/or
errors the speed improvement would
On 08/17/2009 08:12 PM, Remi Collet wrote:
Hi,
Building 5.3.1 snapshot with options
--with-mysql=shared,mysqlnd
--with-mysqli=shared,mysqlnd
--with-pdo-mysql=shared,mysqlnd
create 3 .so files, ok.
But mysqlnd extension still build as static within php core.
It's not an
Top poster!
And Windows only bugs are not critical. That error_log crash alone
should have caused an immediate release weeks ago..
--Jani
On 08/07/2009 01:06 AM, Pierre Joye wrote:
hi Johannes,
I do not have the chance to match this planning. I'll be back from
holidays on Monday and will
On 08/03/2009 07:52 AM, dan...@zoltak.com wrote:
Jani Taskinen wrote:
[snip]
You obviously do not have the correct sources then.
Try get them directly using SVN:
# svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_2/
And if those don't work either, you need to provide a GDB
On 08/03/2009 02:52 PM, dan...@zoltak.com wrote:
Quoting Jani Taskinen jani.taski...@sci.fi:
On 08/03/2009 07:52 AM, dan...@zoltak.com wrote:
Jani Taskinen wrote:
[snip]
Obviously you haven't compiled using --enable-debug OR most likely are
not using the compiled libphp5.so. Check your
On 08/03/2009 03:19 PM, dan...@zoltak.com wrote:
Quoting Jani Taskinen jani.taski...@sci.fi:
Well, this is using PHP 5.2.10. And you were supposed to test the
snapshot. How about the backtrace using latest PHP_5_2 checkout?
I downloaded the latest snap and tar.bz2 it in the php-5.2.10 folder
Dan Zoltak wrote:
Jani Taskinen wrote:
[snip]
There is a bug in 5.2.10 that might cause this, try latest SVN
checkout of PHP_5_2 branch, it should be fixed now.
I've download and tested the latest snap (php5.2-200908020630) and I am
still having the same issue. I have performed an strace
Rasmus Lerdorf wrote:
Jani Taskinen wrote:
Dan Zoltak wrote:
Jani Taskinen wrote:
[snip]
There is a bug in 5.2.10 that might cause this, try latest SVN
checkout of PHP_5_2 branch, it should be fixed now.
I've download and tested the latest snap (php5.2-200908020630) and I
am still having
On 07/31/2009 03:10 AM, dan...@zoltak.com wrote:
[snip]
The above code has been works fine in PHP 5.2.6. In PHP 5.2.10 it works
except when an .htaccess is defined with the following:
--BEGIN SNIP .htaccess--
php_value error_log '/home/st/stu/studio1.com.au/www/logs/php_err.log'
--END SNIP--
I'm just waiting for you to just commit it.. :)
--Jani
On 07/29/2009 12:08 PM, Moriyoshi Koizumi wrote:
Aren't there any interests on this? If you think PHP 6 is gonna cover
all of the functionality that allegedly-cruft mbstring currently
provides, that is almost wrong :-p
Moriyoshi
On Tue,
Gwynne Raskind wrote:
On Jul 27, 2009, at 6:31 PM, Takeshi Abe wrote:
Just to be sure, is there any consensus on this? I thought I should
use svn merge.
README.SVN-RULES says
1. All changes should first go to trunk and then get merged from trunk
(aka MFH'ed) to all other relevant
Dmitry Stogov wrote:
David Zülke wrote:
On 28.07.2009, at 13:32, Dmitry Stogov wrote:
Hi David,
I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final decision.
Can I suggest you not to suggest any other VCS from now on?
If you like some VCS better, just keep that info to yourself, no need to
spam the mailing lists about it.
--Jani
On 07/20/2009 01:38 PM, Arnold Daniels wrote:
Hi,
Can I suggest having a look at GIT (http://git-scm.com). It has
On 07/15/2009 08:49 PM, David Zülke wrote:
Hi there,
attached are patches for http://bugs.php.net/48929.
Big kudos to Tjerk Anne and Arnaud, this forking HTTP server stuff for
testing the stream wrapper is genius.
Ehem..was this ever committed? And don't you have svn access yourself
anyway?
On 07/18/2009 07:03 PM, Sriram Natarajan wrote:
Jani Taskinen wrote:
Sriram Natarajan wrote:
Hi
I was looking into CR:
48774(http://bugs.php.net/bug.php?id=48774thanks=3) and was hoping
if some one can kindly review this patch. This patch does address the
SEGV issue reported in the bug. Can
Sriram Natarajan wrote:
Hi
I was looking into CR:
48774(http://bugs.php.net/bug.php?id=48774thanks=3) and was hoping if
some one can kindly review this patch. This patch does address the SEGV
issue reported in the bug. Can this be applied to PHP 5.3 and PHP 5.2 as
well ?
Index:
On 07/17/2009 01:24 AM, Jani Taskinen wrote:
Rasmus Lerdorf wrote:
One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.
I did a commit today on all 3
On 07/14/2009 05:38 AM, Herman Radtke wrote:
This bug only exists in PHP 5.x. The unicode support in PHP 6 takes
care of it already, but I added a PHP 6 version of the test case as
well.
Committed. I fixed the test to work in all branches. :)
--Jani
--
PHP Internals - PHP Runtime
Uwe Schindler wrote:
Or just to something more generic like php-commits@ ? The same with
zend-commits?
Only php-commits@ is necessary since there is no separate Zend stuff anymore..?
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Rasmus Lerdorf wrote:
One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.
I did a commit today on all 3 branches and it worked fine except for the fact
that
Sriram Natarajan wrote:
Hi
bug tracking system also need the ability to mark a current bug as
duplicate . Currently, all those bugs are marked as 'Bogus'. Also, it
would be nice if we can have the ability to capture related bugs together.
- Sriram
Again: DO NOT TOP POST!!
And we're not
Sriram Natarajan wrote:
Jani Taskinen wrote:
Please don't top post!
And what you ask for is already there.
--Jani
Sriram Natarajan kirjoitti:
Hi
I very much miss the ability to add my email address to the bugs that
I am interested in. This used to allow to me to track its progress. I
Gwynne Raskind kirjoitti:
The conversion from CVS to SVN is complete. CVS read AND write access
has been completely disabled. SVN is now up and running, however *we
Why is CVS read access disabled? I had some patches brewing in my checkouts and
getting them out now is kinda PITA.. Also
Please don't top post!
And what you ask for is already there.
--Jani
Sriram Natarajan kirjoitti:
Hi
I very much miss the ability to add my email address to the bugs that I
am interested in. This used to allow to me to track its progress. I
wasn't not sure, if that is what you meant within
Ilia Alshanetsky wrote:
On 7-Jul-09, at 8:43 PM, Rasmus Lerdorf wrote:
That doesn't really change the timing, especially since you said you
have been using it for 2 years. Why pick the week after the 5.3 release
to propose it for 5.3? It makes very little sense to me, and I think
consensus
Jani Taskinen wrote:
Ilia Alshanetsky wrote:
On 7-Jul-09, at 8:43 PM, Rasmus Lerdorf wrote:
That doesn't really change the timing, especially since you said you
have been using it for 2 years. Why pick the week after the 5.3 release
to propose it for 5.3? It makes very little sense to me
1 - 100 of 810 matches
Mail list logo
