Re: [PHP-DEV] quick polls for 5.3 (sorry missed a couple votes, but they did not affect the results)
Lukas Kahwe Smith wrote: 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. -1 Lukas -1 David +1 Hannes +0 Matt Wilson +0 Greg +0 Derick +1 Elizabeth +0 Lars -1 Stas for now Need more explanation why we need rewrite, what the rewrite does, etc. If there's a good reason and maintainer, then maybe +1. -1 Ilia +0.5 Steph I'd really like to see it in 5.3 because it was supposed to fix several OB issues, but it's probably too late in the cycle now +0 Scott +1 Kalle -1 David S.P. for now Need more explanation why we need rewrite, what the rewrite does, etc. If there's a good reason and maintainer, then maybe +1. -1 Rob +1 Pierre (if it creates non fixable issues during the alpha/RC phases, it can always be reverted. However the code is much cleaner and easier to maintain, if I can use the word easy for the OB code) +0 Arnaud Le Blanc +0 Larry Garfield +0 Lester Caine +0 Konstantin Leboev +1 Jani +0 Jonathan Bond-Caron +0 George Antoniadis +1 Felipe +1 Moriyoshi +0 Karsten Dambekalns +0 Alexey Zakhlestin +1 Guilherme Blanco +1 Marcus = no MFH, very unclear vote result and nobody that raised their hand to take responsibility (yes Pierre I know that you raised your hand on IRC) Hm... I'm still alive, but I feel blamed for not reading a mailing list which has become unmanageable to read. I wrote the code, so I'm probably responsible for it, too. And again, I was asked several times to back port it, so it can be included in 5.3--which doesn't mean I'm insisting on that matter, just to make it clear. I've still got some email addresses which--despite of spam--I am able to read and respond in a reasonable time span. Usually you can even hit me on IRC. Feel free to ask me any questions per mail or on IRC, but don't expect me to read a quadrillion of mails on [EMAIL PROTECTED] Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hello All,
First up thanks for this every efficient thread!
Really makes the life for Johannes and myself a lot easier when we can
so easily get an overview of the opinions on internals.
After having discussed the results, we want to publish our
conclusions ..
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing
if mhash is removed (answer both)
I) enable ext/hash by default
+1 Lukas
+1 David C.
+1 Hannes
+1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Stas
+1 Ilia
+1 Steph
+1 Scott
+1 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+1 Arnaud Le Blanc
+1 Larry Garfield
+0 Lester Caine
+0 Konstantin Leboev
+1 Jani
+1 Jonathan Bond-Caron
+1 George Antoniadis
+0 Felipe
+1 Moriyoshi
= keep ext/hash enabled by default
II) remove ext/mhash
+1 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+0 Greg
+1 Derick
+1 Elizabeth
+1 Lars (Probably hack ZEND_FUNCTION(extension_loaded) to return true
when mhash is passed and throw a deprecation warning. Is pretty easy
but ugly. What would our ZE guys suggest to accomplish something like
that?)
+1 Stas (Can't we make mhash stub extension with dependency on hash
so only thing you get when you load it is that extension_loaded is OK
and no BC break? Dependency would ensure the functions are there, and
we get the bets of both worlds.)
+1 Ilia
-1 Steph BC concerns. Can't we just deprecate it in 5.3 and remove in
6.0?
+1 Scott
+0 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+0 Arnaud Le Blanc
-1 Larry Garfield better to E_DEPRECATE for a version first then remove.
+0 Lester Caine
+0 Konstantin Leboev
+1 Jani
+0 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
+1 Moriyoshi
= remove ext/mhash (someone may propose some stub/magic solution for
extension_loaded('mhash'))
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/
ereg is more or less redundant with ext/preg and is likely to not get
much unicode love for PHP 6, the question is if we should mark it with
a E_DEPRECATED in PHP 5.3
+1 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+1 Greg
-1 Derick
+1 Elizabeth
+1 Lars
-0.5 Stas I'd say not yet, but don't care too much.
+1 Ilia
+1 Steph
+1 Scott
+0 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+1 Arnaud Le Blanc (and allow the --without-ereg switch)
+1 Larry Garfield
+1 Lester Caine
+1 Konstantin Leboev
+1 Jani
+1 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
+1 Moriyoshi
= deprecate ext/ereg and remove in PHP 6
3) resource constants (choose one)
+0 Stas
+0 Larry Garfield
+0 Konstantin Leboev
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
+1 Scott
+1 Arnaud Le Blanc
+1 George Antoniadis
+1 Moriyoshi
b) Should we instead just throw an E_STRICT
+1 Kalle
c) Document as is
+1 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Ilia
+1 Steph
+1 David S.P.
+1 Rob
+1 Pierre
+1 Lester Caine
+1 Jani
+1 Jonathan Bond-Caron
+1 Felipe
= document as is
4) keep ext/phar enabled by default in 5.3?
+1 Lukas
+1 David
-1 Hannes
-1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Stas
+0 Ilia
+1 Steph
+0 Scott
+1 Kalle
+1 David S.P.
+0 Rob
+0 Pierre
+1 Arnaud Le Blanc
+0 Larry Garfield
-1 Lester Caine
+0 Konstantin Leboev
-1 Jani
+1 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
+1 Moriyoshi
= keep ext/phar enabled
5) keep ext/sqlite3 enabled by default in 5.3?
+1 Lukas
+1 David
+0 Hannes
-1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Stas
+1 Ilia
+1 Steph
+1 Scott
+0 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+1 Arnaud Le Blanc
+1 Larry Garfield
-1 Lester Caine
+1 Konstantin Leboev
+1 Jani
+0 Jonathan Bond-Caron
-1 George Antoniadis
+1 Felipe
+1 Moriyoshi
= keep ext/sqlite3 enabled
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
-1 Lukas
-1 David
-0 Hannes
-1 Matt Wilson
+0 Greg
-1 Derick
+0 Elizabeth
+1 Lars
+0 Stas
-1 Ilia
+1 Steph
+1 Scott
+1 Kalle
+0 David S.P.
-1 Rob
+1 Pierre
+0 Arnaud Le Blanc
+1 Larry Garfield
-1 Lester Caine Many people do not use MySQL so it should not be
enabled by default. This is even more important if it gets compiled in
by default in windows builds.
+0 Konstantin Leboev
+1 Jani
-1 Jonathan Bond-Caron would favor mysql by including client in
default installation (Clarification by Johannes: mysqlnd is a PHP-
specific replacement for the MySQL Client Library (libmysql) so adding
mysqlnd as default means including client in default installation.
By using mysqlnd there are no external dependencies left.)
+1 George Antoniadis
+1 Felipe
-1 Moriyoshi
= do not enable by default since there is not enough support to add
something (assumption when in doubt do not add)
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
-1 Lukas
+1 David
-0 Hannes
-1 Matt Wilson
+0 Greg
-1 Derick
+0 Elizabeth
+1 Lars
+0 Stas
-1 Ilia
-1 Steph if it was just one
Re: [PHP-DEV] quick polls for 5.3
On Thu, Nov 13, 2008 at 4:14 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: 1) ext/mhash in 5.3. I) enable ext/hash by default +1 II) remove ext/mhash +1 2) deprecate ereg*. +1 3) resource constants (choose one) a) Should we deprecate constant resources (mostly used to emulate STDIN and friends) b) Should we instead just throw an E_STRICT c) Document as is a 4) keep ext/phar enabled by default in 5.3? +1 5) keep ext/sqlite3 enabled by default in 5.3? +1 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default -1 II) also enable ext/mysql, mysqli and pdo_mysql by default since there will be no external dependencies in this case -1 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. +1 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either (choose one) a) revert in HEAD b) MFH to 5.3 b -- moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hi, Thank you all for participating and raising any issues/concerns in a concise manner. I will tally up the votes sometime over the weekend and discuss the results with Johannes. We will then post what decisions we will take based on the votes (though in some cases we might need to hold off a decision until we have discussed the change with the person that maintains the given code). So in the mean time for all who have not voted, please do so now. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] quick polls for 5.3
On Thu, 2008-11-13 at 09:40 -0500, Jonathan Bond-Caron wrote: 6) enable mysqlnd by default in 5.3? (answer both) -1 both: would favor mysql by including client in default installation For clarification: mysqlnd is a PHP-specific replacement for the MySQL Client Library (libmysql) so adding mysqlnd as default means including client in default installation. By using mysqlnd there are no external dependencies left. johannes -- Johannes Schlüter - MySQL Engineering, Connectors and Client Connectivity Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht München: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wed, Nov 12, 2008 at 9:14 PM, Lukas Kahwe Smith [EMAIL PROTECTED]wrote:
Hi,
here are a few questions that need to be answered ASAP.
If at all possible keep your votes as short as possible. I think all of the
above topics have been discussed quite a lot on the list. So I hope voters
can spare the list needless repetition. Instead if you think that a topic
needs to be discussed, put a short note in your vote under the given topic.
If a number of people also think the topic needs more discussion, then we
can open a new thread dedicated to this topic later this week.
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
+1 +1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
a
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
-1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
+1 +1
7) should Output buffering rewrite MFH? this one comes with some baggage,
we need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
+0
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
b
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
+0
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
C
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
+1
7) should Output buffering rewrite MFH? this one comes with some baggage, we
need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
+1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
+0
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Lukas Kahwe Smith wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing if
mhash is removed (answer both)
I) enable ext/hash by default
0
II) remove ext/mhash
0
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to not
get much unicode love for PHP 6, the question is if we should mark it
with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN
and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
-1
5) keep ext/sqlite3 enabled by default in 5.3?
-1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
-1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
-1
Many people do not use MySQL so it should not be enabled by default. This is
even more important if it gets compiled in by default in windows builds.
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things are
in HEAD and make it clear that they will be available for bug fixing and
BC issues resolving. the risk here is obviously that any BC issues will
be hard to isolate for end users.
Am using output buffering but don't know what effect this has.
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
Don't know.
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wed, Nov 12, 2008 at 10:14 PM, Lukas Kahwe Smith [EMAIL PROTECTED]wrote:
Hi,
here are a few questions that need to be answered ASAP.
If at all possible keep your votes as short as possible. I think all of the
above topics have been discussed quite a lot on the list. So I hope voters
can spare the list needless repetition. Instead if you think that a topic
needs to be discussed, put a short note in your vote under the given topic.
If a number of people also think the topic needs more discussion, then we
can open a new thread dedicated to this topic later this week.
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
0
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
0
4) keep ext/phar enabled by default in 5.3?
0
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
0
7) should Output buffering rewrite MFH? this one comes with some baggage,
we need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
0
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
0
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Best regards,
Konstantin Leboev
Re: [PHP-DEV] quick polls for 5.3
Lukas Kahwe Smith wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing if
mhash is removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to not
get much unicode love for PHP 6, the question is if we should mark it
with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN
and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
-1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
+1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
+1
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things are
in HEAD and make it clear that they will be available for bug fixing and
BC issues resolving. the risk here is obviously that any BC issues will
be hard to isolate for end users.
+1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
a
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] quick polls for 5.3
On Wed Nov 12 02:14 PM, Lukas Kahwe Smith wrote: 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC I) enable ext/hash by default +1 II) remove ext/mhash 0 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ +1 3) resource constants (choose one) c 4) keep ext/phar enabled by default in 5.3? +1 5) keep ext/sqlite3 enabled by default in 5.3? 0 6) enable mysqlnd by default in 5.3? (answer both) -1 both: would favor mysql by including client in default installation 7) should Output buffering rewrite MFH? this one comes with some 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so 0 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wed, Nov 12, 2008 at 10:14 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
+1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
-1
7) should Output buffering rewrite MFH? this one comes with some baggage, we
need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
+0
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
b
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Thu, Nov 13, 2008 at 12:56 PM, Alexey Zakhlestin [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 10:14 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
C is ok
4) keep ext/phar enabled by default in 5.3?
Strongly +1
5) keep ext/sqlite3 enabled by default in 5.3?
0
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
-1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
-1
7) should Output buffering rewrite MFH? this one comes with some baggage, we
need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
+1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
0
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hello Lukas,
Wednesday, November 12, 2008, 8:14:31 PM, you wrote:
Hi,
here are a few questions that need to be answered ASAP.
If at all possible keep your votes as short as possible. I think all
of the above topics have been discussed quite a lot on the list. So I
hope voters can spare the list needless repetition. Instead if you
think that a topic needs to be discussed, put a short note in your
vote under the given topic. If a number of people also think the topic
needs more discussion, then we can open a new thread dedicated to this
topic later this week.
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing
if mhash is removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/
ereg is more or less redundant with ext/preg and is likely to not get
much unicode love for PHP 6, the question is if we should mark it with
a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
+0
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things
are in HEAD and make it clear that they will be available for bug
fixing and BC issues resolving. the risk here is obviously that any BC
issues will be hard to isolate for end users.
+1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
+1
In short, MFH what we can, keep at least one DB in PHP per default.
Enable all by default that does not depend on any library or move to
PECL. Introduce stuff to core, enabled by default that we develop for
mainstream usage. Do not do unneccessary changes, clarify docs always.
And last but not least adhere to KISS and consistency.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On 12.11.2008, at 20:14, Lukas Kahwe Smith wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire
BC break will be that if (extension_loaded('mhash')) will need
fixing if mhash is removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to
not get much unicode love for PHP 6, the question is if we should
mark it with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
c) Document as is
+1
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
-1
II) also enable ext/mysql, mysqli und pdo_mysql by default since
there will be no external dependencies in this case
-1
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things
are in HEAD and make it clear that they will be available for bug
fixing and BC issues resolving. the risk here is obviously that any
BC issues will be hard to isolate for end users.
-1 (unless enough people step up)
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont,
so either (choose one)
b) MFH to 5.3
+1
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wed, Nov 12, 2008 at 20:14, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Hi,
here are a few questions that need to be answered ASAP.
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
C
4) keep ext/phar enabled by default in 5.3?
-1
5) keep ext/sqlite3 enabled by default in 5.3?
+0
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
-0
7) should Output buffering rewrite MFH? this one comes with some baggage, we
+1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
Wait, what? Didn't even know there was a difference. If there is, B.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Nov 12, 2008, at 1:14 PM, Lukas Kahwe Smith wrote:
Hi,
here are a few questions that need to be answered ASAP.
If at all possible keep your votes as short as possible. I think all
of the above topics have been discussed quite a lot on the list. So
I hope voters can spare the list needless repetition. Instead if you
think that a topic needs to be discussed, put a short note in your
vote under the given topic. If a number of people also think the
topic needs more discussion, then we can open a new thread dedicated
to this topic later this week.
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire
BC break will be that if (extension_loaded('mhash')) will need
fixing if mhash is removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
+1 for both
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to
not get much unicode love for PHP 6, the question is if we should
mark it with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
-1, keep as is
4) keep ext/phar enabled by default in 5.3?
-1
5) keep ext/sqlite3 enabled by default in 5.3?
-1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since
there will be no external dependencies in this case
-1 to both
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things
are in HEAD and make it clear that they will be available for bug
fixing and BC issues resolving. the risk here is obviously that any
BC issues will be hard to isolate for end users.
no opinion
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont,
so either (choose one)
a) revert in HEAD
b) MFH to 5.3
+1 to B
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wed, 12 Nov 2008, Lukas Kahwe Smith wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
yes, yes
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg is
more or less redundant with ext/preg and is likely to not get much unicode
love for PHP 6, the question is if we should mark it with a E_DEPRECATED in
PHP 5.3
no
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
yes
5) keep ext/sqlite3 enabled by default in 5.3?
yes
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be
no external dependencies in this case
no, no
7) should Output buffering rewrite MFH? this one comes with some baggage, we
need enough people to actually have a look at how things are in HEAD and make
it clear that they will be available for bug fixing and BC issues resolving.
the risk here is obviously that any BC issues will be hard to isolate for end
users.
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either
(choose one)
a) revert in HEAD
b) MFH to 5.3
a - definitely not b - there is not enough test cases, and there are way
too many changes to see what was changed. From what I can see now,
allowing this enormous big patch into HEAD was also a bad idea. (And
seriously, this shouldn't have been on your list IMO).
Derick
--
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hi,
Am Mittwoch, den 12.11.2008, 20:14 +0100 schrieb Lukas Kahwe Smith:
[...]
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing
if mhash is removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
yes, yes. Probably hack ZEND_FUNCTION(extension_loaded) to return true
when mhash is passed and throw a deprecation warning. Is pretty easy
but ugly. What would our ZE guys suggest to accomplish something like
that?
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/
ereg is more or less redundant with ext/preg and is likely to not get
much unicode love for PHP 6, the question is if we should mark it with
a E_DEPRECATED in PHP 5.3
yes
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
yes
5) keep ext/sqlite3 enabled by default in 5.3?
yes
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
yes
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
yes
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things
are in HEAD and make it clear that they will be available for bug
fixing and BC issues resolving. the risk here is obviously that any BC
issues will be hard to isolate for end users.
abstention
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
abstention
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] quick polls for 5.3
Hi!
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing if
mhash is removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
I) +1
II) Can't we make mhash stub extension with dependency on hash so only
thing you get when you load it is that extension_loaded is OK and no BC
break? Dependency would ensure the functions are there, and we get the
bets of both worlds.
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to not
get much unicode love for PHP 6, the question is if we should mark it
with a E_DEPRECATED in PHP 5.3
-0.5
I'd say not yet, but don't care too much.
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
0
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things are
in HEAD and make it clear that they will be available for bug fixing and
BC issues resolving. the risk here is obviously that any BC issues will
be hard to isolate for end users.
-1 for now
Need more explanation why we need rewrite, what the rewrite does, etc.
If there's a good reason and maintainer, then maybe +1.
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
Same as above.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On 12-Nov-08, at 2:14 PM, Lukas Kahwe Smith wrote:
Hi,
here are a few questions that need to be answered ASAP.
If at all possible keep your votes as short as possible. I think all
of the above topics have been discussed quite a lot on the list. So
I hope voters can spare the list needless repetition. Instead if you
think that a topic needs to be discussed, put a short note in your
vote under the given topic. If a number of people also think the
topic needs more discussion, then we can open a new thread dedicated
to this topic later this week.
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire
BC break will be that if (extension_loaded('mhash')) will need
fixing if mhash is removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
+1 (for both)
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to
not get much unicode love for PHP 6, the question is if we should
mark it with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
(c) +1
4) keep ext/phar enabled by default in 5.3?
-0
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since
there will be no external dependencies in this case
-1 for all
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things
are in HEAD and make it clear that they will be available for bug
fixing and BC issues resolving. the risk here is obviously that any
BC issues will be hard to isolate for end users.
-1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont,
so either (choose one)
a) revert in HEAD
b) MFH to 5.3
+1 (b)
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On 12 Nov 2008, at 14:14, Lukas Kahwe Smith wrote:
Hi,
here are a few questions that need to be answered ASAP.
If at all possible keep your votes as short as possible. I think all
of the above topics have been discussed quite a lot on the list. So
I hope voters can spare the list needless repetition. Instead if you
think that a topic needs to be discussed, put a short note in your
vote under the given topic. If a number of people also think the
topic needs more discussion, then we can open a new thread dedicated
to this topic later this week.
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire
BC break will be that if (extension_loaded('mhash')) will need
fixing if mhash is removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to
not get much unicode love for PHP 6, the question is if we should
mark it with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
+1
b) Should we instead just throw an E_STRICT
c) Document as is
4) keep ext/phar enabled by default in 5.3?
+0
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
+1
II) also enable ext/mysql, mysqli und pdo_mysql by default since
there will be no external dependencies in this case
-1, i'd like to see ext/mysql removed
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things
are in HEAD and make it clear that they will be available for bug
fixing and BC issues resolving. the risk here is obviously that any
BC issues will be hard to isolate for end users.
-0
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont,
so either (choose one)
a) revert in HEAD
b) MFH to 5.3
+1
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hi Lukas,
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing if
mhash is removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
-1, BC concerns. Can't we just deprecate it in 5.3 and remove in 6.0?
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/
ereg is more or less redundant with ext/preg and is likely to not get
much unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN
and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
C
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
+1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
-1... if it was just one extension OK, but three is too many
7) should Output buffering rewrite MFH? this one comes with some baggage,
we need enough people to actually have a look at how things are in HEAD
and make it clear that they will be available for bug fixing and BC
issues resolving. the risk here is obviously that any BC issues will be
hard to isolate for end users.
+0.5.. I'd really like to see it in 5.3 because it was supposed to fix
several OB issues, but it's probably too late in the cycle now
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
0 (not enough insight to vote on this)
Thanks,
- Steph
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+0
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+0
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
b
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+0
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
+1 on both
7) should Output buffering rewrite MFH? this one comes with some baggage, we
need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
+1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
+0
--
Kalle Sommer Nielsen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing
if mhash is removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
+1 both
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to not
get much unicode love for PHP 6, the question is if we should mark it
with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
-0
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
-1 both
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things
are in HEAD and make it clear that they will be available for bug
fixing and BC issues resolving. the risk here is obviously that any BC
issues will be hard to isolate for end users.
-1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
b) MFH to 5.3
b
Rob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
hi Lukas!
Thanks for this nice little list, 1st class troll killer :)
On Wed, Nov 12, 2008 at 8:14 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
c) Document as is
+1
4) keep ext/phar enabled by default in 5.3?
0
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
+1
7) should Output buffering rewrite MFH? this one comes with some baggage, we
need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
+1 (if it creates non fixable issues during the alpha/RC phases, it
can always be reverted. However the code is much cleaner and easier
to maintain, if I can use the word easy for the OB code)
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
b) MFH to 5.3
+1 (there is tests, there is people taking of it if there are issues,
more tests can be added as wish, it removes duplicate codes)
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
c) Document as is
+1
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
I'd say personally +1 because I have it enabled everywhere already but
thinking in a larger user base where not everyone is using mysql I
have to say -1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
+1 if it ends up turned on by default, -1 otherwise.
7) should Output buffering rewrite MFH? this one comes with some baggage, we
need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
-1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
b) MFH to 5.3
+1
--
Slan,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wednesday 12 November 2008 20:14:31 Lukas Kahwe Smith wrote:
Hi,
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing
if mhash is removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
-0
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/
ereg is more or less redundant with ext/preg and is likely to not get
much unicode love for PHP 6, the question is if we should mark it with
a E_DEPRECATED in PHP 5.3
+1 (and allow the --without-ereg switch)
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
a
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
-0
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things
are in HEAD and make it clear that they will be available for bug
fixing and BC issues resolving. the risk here is obviously that any BC
issues will be hard to isolate for end users.
+0
Arnaud
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wednesday 12 November 2008 1:14:31 pm Lukas Kahwe Smith wrote:
Hi,
here are a few questions that need to be answered ASAP.
If at all possible keep your votes as short as possible. I think all
of the above topics have been discussed quite a lot on the list. So I
hope voters can spare the list needless repetition. Instead if you
think that a topic needs to be discussed, put a short note in your
vote under the given topic. If a number of people also think the topic
needs more discussion, then we can open a new thread dedicated to this
topic later this week.
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing
if mhash is removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
-1, better to E_DEPRECATE for a version first then remove.
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/
ereg is more or less redundant with ext/preg and is likely to not get
much unicode love for PHP 6, the question is if we should mark it with
a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
+0
4) keep ext/phar enabled by default in 5.3?
+0
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
+1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
+1
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things
are in HEAD and make it clear that they will be available for bug
fixing and BC issues resolving. the risk here is obviously that any BC
issues will be hard to isolate for end users.
+0
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
+0
--
Larry Garfield
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
