# quick polls for 5.3 - Thread: https://externals.io/message/41867 - Original archive: https://news-web.php.net/php.internals/41867 - Started by Lukas Kahwe Smith on 2008-11-12T19:14:31+00:00 - Messages: 35 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/41867.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #41867 — Lukas Kahwe Smith — 2008-11-12T19:14:31+00:00 URL: https://externals.io/message/41867#41867 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 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 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 4) keep ext/phar enabled by default in 5.3? 5) keep ext/sqlite3 enabled by default in 5.3? 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 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 regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41868 — Lukas Kahwe Smith — 2008-11-12T19:18:01+00:00 URL: https://externals.io/message/41867#41868 · In reply to: #41867 > 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 mls@pooteeweet.org --- ## #41869 — David Coallier — 2008-11-12T19:25:58+00:00 URL: https://externals.io/message/41867#41869 · In reply to: #41867 > 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 --- ## #41870 — Hannes Magnusson — 2008-11-12T19:28:13+00:00 URL: https://externals.io/message/41867#41870 · In reply to: #41867 > 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 --- ## #41872 — Matt Wilson — 2008-11-12T19:29:26+00:00 URL: https://externals.io/message/41867#41872 · In reply to: #41867 > 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 > mls@pooteeweet.org --- ## #41873 — Greg Beaver — 2008-11-12T19:30:24+00:00 URL: https://externals.io/message/41867#41873 · In reply to: #41867 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 +0 (no opinion) > 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? +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 (no opinion) > II) also enable ext/mysql, mysqli und pdo_mysql by default since there > will be no external dependencies in this case +0 (no opinion) > 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 (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 +0 (no opinion) Greg --- ## #41874 — Derick Rethans — 2008-11-12T19:48:13+00:00 URL: https://externals.io/message/41867#41874 · In reply to: #41867 > 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 --- ## #41875 — Elizabeth M Smith — 2008-11-12T19:55:44+00:00 URL: https://externals.io/message/41867#41875 · In reply to: #41867 [snip] > 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 (go ahead, let them shoot in foot) > 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 to both (don't care) > 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 Thanks, Elizabeth Smith --- ## #41876 — Lars Strojny — 2008-11-12T20:00:08+00:00 URL: https://externals.io/message/41867#41876 · In reply to: #41867 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 --- ## #41877 — Stanislav Malyshev — 2008-11-12T20:02:52+00:00 URL: https://externals.io/message/41867#41877 · In reply to: #41867 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 stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41878 — Ilia Alshanetsky — 2008-11-12T20:04:44+00:00 URL: https://externals.io/message/41867#41878 · In reply to: #41867 > 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 --- ## #41879 — Steph Fox — 2008-11-12T20:15:56+00:00 URL: https://externals.io/message/41867#41879 · In reply to: #41867 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 > mls@pooteeweet.org --- ## #41880 — Scott MacVicar — 2008-11-12T20:19:14+00:00 URL: https://externals.io/message/41867#41880 · In reply to: #41867 > 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 --- ## #41881 — Kalle Sommer Nielsen — 2008-11-12T20:39:14+00:00 URL: https://externals.io/message/41867#41881 · In reply to: #41867 > 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 --- ## #41882 — David Soria Parra — 2008-11-12T20:57:47+00:00 URL: https://externals.io/message/41867#41882 · In reply to: #41867 > 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 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 > 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 stas: If it is needed and good reasons to mfh and a maintainer than +1. david --- ## #41884 — Rob Richards — 2008-11-12T21:09:26+00:00 URL: https://externals.io/message/41867#41884 · In reply to: #41867 > 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 --- ## #41886 — Pierre Joye — 2008-11-12T21:31:06+00:00 URL: https://externals.io/message/41867#41886 · In reply to: #41867 hi Lukas! Thanks for this nice little list, 1st class troll killer :) > 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 --- ## #41887 — Arnaud Le Blanc — 2008-11-13T04:02:05+00:00 URL: https://externals.io/message/41867#41887 · In reply to: #41867 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 --- ## #41888 — Larry Garfield — 2008-11-13T04:27:08+00:00 URL: https://externals.io/message/41867#41888 · In reply to: #41867 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 larry@garfieldtech.com --- ## #41889 — Lester Caine — 2008-11-13T10:42:36+00:00 URL: https://externals.io/message/41867#41889 · In reply to: #41867 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 --- ## #41890 — Konstantin Leboev — 2008-11-13T11:05:16+00:00 URL: https://externals.io/message/41867#41890 · In reply to: #41867 On Wed, Nov 12, 2008 at 10: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 > 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 > mls@pooteeweet.org > > > -- > > > > -- Best regards, Konstantin Leboev --- ## #41892 — Jani Taskinen — 2008-11-13T12:56:37+00:00 URL: https://externals.io/message/41867#41892 · In reply to: #41867 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 --- ## #41894 — Jonathan Bond-Caron — 2008-11-13T14:40:27+00:00 URL: https://externals.io/message/41867#41894 · In reply to: #41867 > 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 --- ## #41895 — Karsten Dambekalns — 2008-11-13T14:48:04+00:00 URL: https://externals.io/message/41867#41895 · In reply to: #41867 Hi. 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 +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 > 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 for 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. abstain > 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 abstain Regards, Karsten --- ## #41896 — Alexey Zakhlestin — 2008-11-13T14:56:40+00:00 URL: https://externals.io/message/41867#41896 · In reply to: #41867 > 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/ --- Next page: https://externals.io/message/41867.md?page=2