[VOTE] Removal of curl-wrappers

php.internals

Pierrick Charron

13 years ago
Hi folks, I just opened a vote for the curl-wrappers removal in 5.5. Since we are in a tight schedule, the vote duration will only be a week and will end April 24th. You can vote there : https://wiki.php.net/rfc/curl-wrappers-removal-rfc#vote Regards, Pierrick

David Soria Parra

13 years ago
On 2013-04-17, Pierrick Charron <pierrick@adoy.net> wrote:
> --001a11c37cdc78c2e304da95cfde > Content-Type: text/plain; charset=ISO-8859-1 > > Hi folks, > > I just opened a vote for the curl-wrappers removal in 5.5. Since we are in > a tight schedule, the vote duration will only be a week and will end April > 24th. > > You can vote there : https://wiki.php.net/rfc/curl-wrappers-removal-rfc#vote
As a friendly reminder. I tag beta4 on Wednesday around 10:00 UTC. Is this getting into before or not? David

Pierrick Charron

13 years ago
Hi, The vote is supposed to end on April 24th, but if there is no objection, I will end it tomorrow and merge it if there is no change in the vote results. Pierrick On 22 April 2013 04:58, David Soria Parra <dsp@php.net> wrote:

Pierrick Charron

13 years ago
David, All, I just committed the patch to remove curl-wrappers from PHP5.5. It 's one day before schedule but we need to make sure the merge was done before the new beta release. Pierrick On 22 April 2013 13:10, Pierrick Charron <pierrick@adoy.net> wrote:

Arpad Ray

13 years ago
Hi Pierrick, Why the big rush? There have been three more votes against removing it in PHP 5.5 since your last email yesterday so I don't think closing the vote early is warranted, but I'm in general confused about the rush to do this in PHP 5.5 anyway. In principle I'm in favour of moving it to PECL until it's stable, but since it's part of the core already and not causing active harm I really don't see why that can't wait until PHP.next, and we use the interim to warn/educate users. I think the decision to remove a feature so late in the release process should err heavily on the side of caution, and this process has been quite the opposite. (Is a 6-line RFC a record? ;) Regards, Arpad On Tue, Apr 23, 2013 at 10:05 PM, Pierrick Charron <pierrick@adoy.net>wrote:

Kalle Sommer Nielsen

13 years ago
Hi 2013/4/24 Arpad Ray <arraypad@gmail.com>:
> Hi Pierrick, > > Why the big rush? There have been three more votes against removing it in > PHP 5.5 since your last email yesterday so I don't think closing the vote > early is warranted, but I'm in general confused about the rush to do this > in PHP 5.5 anyway.
We still have 75% vs 25% on that vote if you account for those new votes, doesn't make much of a difference (like on the ZO+ vote). That it is a rush was favored by the RMs to get it removed prior RC stage to follow our release schedule.
> In principle I'm in favour of moving it to PECL until it's stable, but > since it's part of the core already and not causing active harm I really > don't see why that can't wait until PHP.next, and we use the interim to > warn/educate users.
I in all honestly doubt anyone is gonna work actively on that when its moved to PECL, same as some of the extensions we in early versions moved to PECL to have releases there but never had any, but it would be nice indeed if someone did. No matter how much we advertise it in our manual, or even front page news, its limited in terms of far it will reach, and the only action to take against removing such "harm" as a buggy feature can cause is far better off to be removed as nobody will see our big red box saying "Don't enable this in production". I personally would consider the use of enabling the cURL wrapper(s) the same as enabling safe_mode in 5.3, its things you "simply do not do" but our userbase does it anyway since we grant them the ability to do so and the only way to stop that is to make a stand and remove it if its not fixed. Now I do realize that removing something is a temporary fix, but in this case its an experimental feature.
> I think the decision to remove a feature so late in the release process > should err heavily on the side of caution, and this process has been quite > the opposite. (Is a 6-line RFC a record? ;)
What more do you want than a 6 liner (its actually 7 including the patch link) RFC, it goes straight to the point.
-- regards, Kalle Sommer Nielsen kalle@php.net