quick polls for 5.3 View as Markdown

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

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

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

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

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

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

[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

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

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

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

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

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

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

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

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

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

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

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

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

On Wed, Nov 12, 2008 at 10:14 PM, Lukas Kahwe Smith mls@pooteeweet.orgwrote:

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

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

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

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

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/

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
mls@pooteeweet.org

Best regards,
Marcus

On Wed, Nov 12, 2008 at 9:14 PM, Lukas Kahwe Smith mls@pooteeweet.orgwrote:

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
mls@pooteeweet.org

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

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

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 extension OK, but three is too many
-1 Scott, i'd like to see ext/mysql removed
+1 Kalle
+0 David S.P.
-1 Rob
+1 Pierre
+0 Arnaud Le Blanc
+1 Larry Garfield
-1 Lester Caine
+0 Konstantin Leboev
+1 Jani
-1 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
-1 Moriyoshi

=> since 6)I) was not accepted this vote is not relevant, albeit its
also not clear enough to change anything

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

=> 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)

8. MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
   either (choose one)
   +0 Greg
   +0 Lars
   +0 Steph
   +0 Kalle
   +0 Arnaud Le Blanc
   +0 Larry Garfield
   +0 Lester Caine
   +0 Konstantin Leboev
   +0 Jonathan Bond-Caron
   +0 Felipe

a) revert in HEAD
+1 Derick 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).
+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 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 Jani

b) MFH to 5.3
+1 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+1 Elizabeth
+1 Ilia
+1 Scott
+1 Rob
+1 Pierre (there is tests, there is people taking of it if there are
issues,
more tests can be added as wish, it removes duplicate codes)
+1 George Antoniadis
+1 Moriyoshi

=> Derick is the maintainer of ext/mcrypt and he opposes the change
due to the lack of tests, so anyone willing to write more tests? then
again on gcov mcrypt shows up with 88%, which looks decent, but
obviously this number does not tell the entire story. also alot of
people felt it would be good to MFH, so Derick please take this into
account.

regards,
Lukas

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
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+1 Marcus
+1 Guilherme Blanco

=> 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
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+1 Marcus
+1 Guilherme Blanco

=> 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
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+1 Marcus
+1 Guilherme Blanco

=> 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
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+1 Marcus
+1 Guilherme Blanco

=> 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
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+1 Marcus
+1 Guilherme Blanco

=> 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
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+0 Guilherme Blanco
+1 Marcus

=> 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
+0 Karsten Dambekalns
+1 Alexey Zakhlestin
-1 Guilherme Blanco
+0 Marcus

=> 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 extension OK, but three is too many
-1 Scott, i'd like to see ext/mysql removed
+1 Kalle
+0 David S.P.
-1 Rob
+1 Pierre
+0 Arnaud Le Blanc
+1 Larry Garfield
-1 Lester Caine
+0 Konstantin Leboev
+1 Jani
-1 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
-1 Moriyoshi
+0 Karsten Dambekalns
-1 Alexey Zakhlestin
-1 Guilherme Blanco
+0 Marcus

=> since 6)I) was not accepted this vote is not relevant, albeit its
also not clear enough to change anything

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)

8. MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
   either (choose one)
   +0 Greg
   +0 Lars
   +0 Steph
   +0 Kalle
   +0 Arnaud Le Blanc
   +0 Larry Garfield
   +0 Lester Caine
   +0 Konstantin Leboev
   +0 Jonathan Bond-Caron
   +0 Felipe
   +0 Karsten Dambekalns
   +0 Guilherme Blanco

a) revert in HEAD
+1 Derick 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).
+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 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 Jani

b) MFH to 5.3
+1 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+1 Elizabeth
+1 Ilia
+1 Scott
+1 Rob
+1 Pierre (there is tests, there is people taking of it if there are
issues,
more tests can be added as wish, it removes duplicate codes)
+1 George Antoniadis
+1 Moriyoshi
+1 Alexey Zakhlestin
+1 Marcus

=> Derick is the maintainer of ext/mcrypt and he opposes the change
due to the lack of tests, so anyone willing to write more tests? then
again on gcov mcrypt shows up with 88%, which looks decent, but
obviously this number does not tell the entire story. also alot of
people felt it would be good to MFH, so Derick please take this into
account.

regards,
Lukas