RE: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, De : Pierre Joye [mailto:pierre@gmail.com] So we do not want to kill them because they are still used (but dead). But we may come with some wrapper to replace almost all the features provided by the dead libs? At least for mcrypt, good luck to anyone willing to do that for imap ;). It may be naive but, for imap, what about writing a wrapper between the imap functions and the Horde/Imap_Client lib, as it works well and is at least as fast as the original C extension. We can embed the lib and the wrapper in a PHP extension (reviving the idea of embedding PHP code in an extension) and rename every public symbols to keep them private (they would not be usable from user code). This would probably be much easier than rewriting the imap extension using libcurl or another imap C lib. Anyway, that's just an idea as I don't know yet if the Horde library provides every features we need. It is distributed under 'LGPL version 2.1', would it allow to embed it in a PHP extension ? So, please tell me if it's worth going a little further. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Jordi, On Wed, February 11, 2015 11:40, Jordi Boggiano wrote: On 09/02/2015 22:29, Anatol Belski wrote: ext/imap ext/mcrypt ext/pdo_dblib Sorry if this was suggested already but if those are not maintained much and should not be used further ideally, shouldn't we add E_DEPRECATED to them at least? I understand that they are kept to avoid making the upgrade path harsher, but it's also not great to let they linger on forever with no notice to users that they are doing something wrong. that was not suggested yet. IMHO the idea is healthy at least for imap and mcrypt. I also think the most reasons to vote for the non removal was the lack on alternatives as well, not just because the dependencies are unsupported. And another RFC were needed for this, obviously. I'm not disposed for yet another one ATM, but that doesn't mean only me could do that. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi all, On Wed, Feb 11, 2015 at 8:20 PM, Andrey Andreev n...@devilix.net wrote: On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano j.boggi...@seld.be wrote: On 09/02/2015 22:29, Anatol Belski wrote: ext/imap ext/mcrypt ext/pdo_dblib Sorry if this was suggested already but if those are not maintained much and should not be used further ideally, shouldn't we add E_DEPRECATED to them at least? I understand that they are kept to avoid making the upgrade path harsher, but it's also not great to let they linger on forever with no notice to users that they are doing something wrong. I don't think it has been suggested already, but I agree - should be deprecated. Vote is vote. Why don't we deprecate them by documentation with obvious warning? We cannot deprecate them immediately, anyway. Is there any objection for deprecation by document? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Fri, Feb 13, 2015 at 3:51 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Feb 11, 2015 at 8:20 PM, Andrey Andreev n...@devilix.net wrote: On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano j.boggi...@seld.be wrote: On 09/02/2015 22:29, Anatol Belski wrote: ext/imap ext/mcrypt ext/pdo_dblib Sorry if this was suggested already but if those are not maintained much and should not be used further ideally, shouldn't we add E_DEPRECATED to them at least? I understand that they are kept to avoid making the upgrade path harsher, but it's also not great to let they linger on forever with no notice to users that they are doing something wrong. I don't think it has been suggested already, but I agree - should be deprecated. Vote is vote. Why don't we deprecate them by documentation with obvious warning? We cannot deprecate them immediately, anyway. Is there any objection for deprecation by document? So we do not want to kill them because they are still used (but dead). But we may come with some wrapper to replace almost all the features provided by the dead libs? At least for mcrypt, good luck to anyone willing to do that for imap ;). But now we should deprecate them but deprecation has lost its meaning as we vote on the actual removal, which may be rejected. So basically, unless we clearly have no chance to have a replacement, I am totally against adding yet some deprecation notices, not if adding a deprecation is actually followed by a removal, read: Vote for deprecation means removal in next. But if it is not the case and we keep deprecated features forever, then we may just kill the deprecation flag instead. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Pierre, On Fri, Feb 13, 2015 at 6:36 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Feb 13, 2015 at 3:51 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Feb 11, 2015 at 8:20 PM, Andrey Andreev n...@devilix.net wrote: On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano j.boggi...@seld.be wrote: On 09/02/2015 22:29, Anatol Belski wrote: ext/imap ext/mcrypt ext/pdo_dblib Sorry if this was suggested already but if those are not maintained much and should not be used further ideally, shouldn't we add E_DEPRECATED to them at least? I understand that they are kept to avoid making the upgrade path harsher, but it's also not great to let they linger on forever with no notice to users that they are doing something wrong. I don't think it has been suggested already, but I agree - should be deprecated. Vote is vote. Why don't we deprecate them by documentation with obvious warning? We cannot deprecate them immediately, anyway. Is there any objection for deprecation by document? So we do not want to kill them because they are still used (but dead). But we may come with some wrapper to replace almost all the features provided by the dead libs? At least for mcrypt, good luck to anyone willing to do that for imap ;). But now we should deprecate them but deprecation has lost its meaning as we vote on the actual removal, which may be rejected. So basically, unless we clearly have no chance to have a replacement, I am totally against adding yet some deprecation notices, not if adding a deprecation is actually followed by a removal, read: Vote for deprecation means removal in next. But if it is not the case and we keep deprecated features forever, then we may just kill the deprecation flag instead. Isn't better to deprecate them in document than nothing? That's what I thought for now. I'm looking forward new crypt extension, BTW! When it is available, we may have vote again. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 09/02/2015 22:29, Anatol Belski wrote: ext/imap ext/mcrypt ext/pdo_dblib Sorry if this was suggested already but if those are not maintained much and should not be used further ideally, shouldn't we add E_DEPRECATED to them at least? I understand that they are kept to avoid making the upgrade path harsher, but it's also not great to let they linger on forever with no notice to users that they are doing something wrong. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Jordi Boggiano wrote on 11/02/2015 10:40: On 09/02/2015 22:29, Anatol Belski wrote: ext/imap ext/mcrypt ext/pdo_dblib Sorry if this was suggested already but if those are not maintained much and should not be used further ideally, shouldn't we add E_DEPRECATED to them at least? I understand that they are kept to avoid making the upgrade path harsher, but it's also not great to let they linger on forever with no notice to users that they are doing something wrong. I guess that's a discussion that can be had on a case-by-case basis, now we've bulk-voted the easy cases out of the way. Deprecation only really makes sense if there is a clear upgrade path for users, or a specific message to give them. For instance, I'm currently using PDO_DBLIB, and had no idea I was doing something wrong, or what I should be doing instead. And many people have already pointed out that ext/mcrypt needs some special thought, so just slapping a deprecation notice somewhere isn't really that useful. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano j.boggi...@seld.be wrote: On 09/02/2015 22:29, Anatol Belski wrote: ext/imap ext/mcrypt ext/pdo_dblib Sorry if this was suggested already but if those are not maintained much and should not be used further ideally, shouldn't we add E_DEPRECATED to them at least? I understand that they are kept to avoid making the upgrade path harsher, but it's also not great to let they linger on forever with no notice to users that they are doing something wrong. I don't think it has been suggested already, but I agree - should be deprecated. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 10 Feb 2015, at 9:29 am, Anatol Belski anatol@belski.net wrote: Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Does this mean PHP will be taking on the role of maintaining libmcrypt as well? If a security issue is found, what is the course of action? Cheers, David Sent from my iPhone -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 10 February 2015 21:38:02 GMT, David Muir davidkm...@gmail.com wrote: On 10 Feb 2015, at 9:29 am, Anatol Belski anatol@belski.net wrote: Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Does this mean PHP will be taking on the role of maintaining libmcrypt as well? If a security issue is found, what is the course of action? It means people want to find some more friendly way of moving forward rather than deleting the extension and letting users deal with the consequences. I don't think anyone has suggested maintaining the underlying library. Several have suggested attempting to build at least a partial compatibility layer on top of openssl or other maintained libraries. Others have suggested adding aggressive warnings whenever the extension is used. I'm sure more suggestions will follow. What is clear is that *something* should be done, but that consensus was that simple removal was not appropriate in this case. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi David, On Tue, February 10, 2015 22:38, David Muir wrote: On 10 Feb 2015, at 9:29 am, Anatol Belski anatol@belski.net wrote: Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity 28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd 26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd 25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Does this mean PHP will be taking on the role of maintaining libmcrypt as well? If a security issue is found, what is the course of action? not that I knew, libmcrypt is not maintained. An alternative were openssl probably. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi David, On Tue, February 10, 2015 22:38, David Muir wrote: On 10 Feb 2015, at 9:29 am, Anatol Belski anatol@belski.net wrote: Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity 28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd 26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd 25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Does this mean PHP will be taking on the role of maintaining libmcrypt as well? If a security issue is found, what is the course of action? not that I knew, libmcrypt is not maintained. An alternative were openssl probably. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Adam, On Wed, February 11, 2015 00:53, Adam Harvey wrote: Finally, Anatol's tally was wrong for this one: it was 17:3 for removal. That's a pretty strong indicator by itself. Yeah, my typo, thanks for the correction :) Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Paul, On Wed, February 11, 2015 00:29, Paul Dragoonis wrote: On Tue, Feb 10, 2015 at 11:14 PM, Kalle Sommer Nielsen ka...@php.net mailto:ka...@php.net wrote: Hi Paul 2015-02-10 23:59 GMT+01:00 Paul Dragoonis dragoo...@gmail.com mailto:dragoo...@gmail.com : Did you accidentally miss out mssql? it resultes in significant resistance to leave core, such as mcrypt and ignoring mathematical numbers, from a practical basis I'd like to see mssql kept in core. Who's with me ? I'd like to see mssql kept as well, only makes more sense as we also have pdo_dblib. I wouldn't mind looking into some fixes to it or porting it once I get my FreeTDS or ntwdblib configuration setup here, as there is a fair bit of cleanup I'd like to do with it. It's common sense that if something receives significant resistance then there's usually a good reason for it and it shouldn't be ignored regardless of how mathematically accurate it may seem to exclude it. Let's keep MSSQL in. you've probably seen that some items was removed from the voting short after it was started. People raised their voices telling they're going to maintain those items. As the goal was not just blindly removing something, but getting rid of unmaintained stuff to better concentrate on the end goal. Now, it is probably no use crying after spilt milk, but the PECL doors are always open anyway. But aside - really huge -1 on what you say about significant resistance and pure math. Either we have and respect the voting process or not. Even if you say it about a misleading typo result. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 10 February 2015 at 21:38, David Muir davidkm...@gmail.com wrote: Does this mean PHP will be taking on the role of maintaining libmcrypt as well? That's not what it means, no. If a security issue is found, what is the course of action? Well, what happened when there was vulnerabilities in OpenSSL? I've been thinking quite hard about what we should do with regard to mcrypt. We definitely need a plan to sunset it, but we can't really do that without a readily available replacement. It's understandable if people do not want to use OpenSSL as an alternative. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski anatol@belski.net wrote: Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib Did you accidentally miss out mssql? it resultes in significant resistance to leave core, such as mcrypt and ignoring mathematical numbers, from a practical basis I'd like to see mssql kept in core. Who's with me ? I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Paul 2015-02-10 23:59 GMT+01:00 Paul Dragoonis dragoo...@gmail.com: Did you accidentally miss out mssql? it resultes in significant resistance to leave core, such as mcrypt and ignoring mathematical numbers, from a practical basis I'd like to see mssql kept in core. Who's with me ? I'd like to see mssql kept as well, only makes more sense as we also have pdo_dblib. I wouldn't mind looking into some fixes to it or porting it once I get my FreeTDS or ntwdblib configuration setup here, as there is a fair bit of cleanup I'd like to do with it. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 10 February 2015 at 23:29, Paul Dragoonis dragoo...@gmail.com wrote: It's common sense that if something receives significant resistance then there's usually a good reason for it and it shouldn't be ignored regardless of how mathematically accurate it may seem to exclude it. Let's keep MSSQL in. https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extmssql Where is the significant resistance? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 11 February 2015 at 06:59, Paul Dragoonis dragoo...@gmail.com wrote: On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski anatol@belski.net wrote: ext/mssql 17:13 Did you accidentally miss out mssql? it resultes in significant resistance to leave core, such as mcrypt and ignoring mathematical numbers, from a practical basis I'd like to see mssql kept in core. Who's with me ? Since it's apparently my week for this, I'll provide the case for the defence (or why I voted for removal, anyway): - The API is awful in the exact same ways the ext/mysql API was awful — it makes it far harder to write secure code than it should be. - Actually, it's worse than that, because there's no charset-aware escaping function at all: the only option is addslashes(), which has interesting security implications if you're using certain charsets. - It's buggy. Some of the bugs are due to the underlying library (which is mostly dead); some are in our code, but there are some fundamental issues — basic data types (nvarchar(128), for example) aren't supported, field names are truncated, stored procedure calls are problematic, and probably many more things that I've forgotten. - The bugs probably aren't going to be fixed. ext/mssql averages about one to two non-whitespace, non-copyright-year-increment commits a year. A cursory look at the bug tracker (or my ##php logs) will tell you that it's not because it's stable and free of bugs. - There are multiple better options: using ODBC is almost always more stable, and while PDO_dblib has some of the same problems due to FreeTDS, at least you're using PDO's better (by which I mostly mean harder to misuse) API. In my mind, this is analogous to removing ext/mysql: it's the right thing to do for our users because it promotes better practices and gets rid of an extension that has even more technical issues than that one did. Finally, Anatol's tally was wrong for this one: it was 17:3 for removal. That's a pretty strong indicator by itself. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Tue, Feb 10, 2015 at 11:36 PM, Leigh lei...@gmail.com wrote: On 10 February 2015 at 23:29, Paul Dragoonis dragoo...@gmail.com wrote: It's common sense that if something receives significant resistance then there's usually a good reason for it and it shouldn't be ignored regardless of how mathematically accurate it may seem to exclude it. Let's keep MSSQL in. https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extmssql Where is the significant resistance? The original email said 17:13 i.e: I guess the mail was wrong then.
[PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
