Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error)
Cc: internals Mailing List <internals@lists.php.net>
Message-ID: <97B8F1EF-1F51-48A6-92CC-9563C99B648E@macvicar.net>
To: Lukas Kahwe Smith <mls@pooteeweet.org>
In-Reply-To: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 12 Nov 2008 15:19:14 -0500
References: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org>
X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  On 12 Nov 2008, at 14:14, Lukas Kahwe Smith wrote: > Hi, >
	> here are a few questions that need to be answered ASAP. > > If at all possible
	keep your votes as short as possible. I think all > of the above topics have
	been discussed quite a lot on the list. So > I hope voters can spare the
	list needless repetition. Instead if you > think that a topic needs to be
	discussed, put a short note in your > vote under the given topic. If a number
	of people also think the > topic needs more discussion, then we can open
	a new thread dedicated > to this topic later this week. > > 1) ext/mhash in
	5.3. ext/hash has all the functions, so the entire > BC break will be that
	"if (extension_loaded('mhash'))" will need > fixing if mhash is removed (answer
	both) > I) enable ext/hash by default +1 > > II) remove ext/mhash +1 [...]
	Content analysis details:   (-4.4 points, 5.0 required)
	pts rule name              description
	---- ---------------------- --------------------------------------------------
	-1.8 ALL_TRUSTED            Passed through trusted hosts only via SMTP
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
Subject: Re: [PHP-DEV] quick polls for 5.3
From: scott@macvicar.net (Scott MacVicar)

On 12 Nov 2008, at 14:14, Lukas Kahwe Smith wrote:

> Hi,
>
> here are a few questions that need to be answered ASAP.
>
> If at all possible keep your votes as short as possible. I think all  
> of the above topics have been discussed quite a lot on the list. So  
> I hope voters can spare the list needless repetition. Instead if you  
> think that a topic needs to be discussed, put a short note in your  
> vote under the given topic. If a number of people also think the  
> topic needs more discussion, then we can open a new thread dedicated  
> to this topic later this week.
>
> 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire  
> BC break will be that "if (extension_loaded('mhash'))" will need  
> fixing if mhash is removed (answer both)
> I) enable ext/hash by default
+1
>
> II) remove ext/mhash
+1

>
>
> 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since  
> ext/ereg is more or less redundant with ext/preg and is likely to  
> not get much unicode love for PHP 6, the question is if we should  
> mark it with a E_DEPRECATED in PHP 5.3
>

+1
> 3) resource constants (choose one)
> a) Should we deprecate constant resources (mostly used to emulate  
> STDIN and friends)
+1
>
> b) Should we instead just throw an E_STRICT
> c) Document as is
>
> 4) keep ext/phar enabled by default in 5.3?
+0
>
>
> 5) keep ext/sqlite3 enabled by default in 5.3?
>
+1

> 6) enable mysqlnd by default in 5.3? (answer both)
> I) enable mysqlnd by default
+1
>
> II) also enable ext/mysql, mysqli und pdo_mysql by default since  
> there will be no external dependencies in this case
-1, i'd like to see ext/mysql removed
>
>
> 7) should Output buffering rewrite MFH? this one comes with some  
> baggage, we need enough people to actually have a look at how things  
> are in HEAD and make it clear that they will be available for bug  
> fixing and BC issues resolving. the risk here is obviously that any  
> BC issues will be hard to isolate for end users.

-0
>
>
> 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont,  
> so either (choose one)
> a) revert in HEAD
> b) MFH to 5.3

+1

Scott