Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] orphan extensions cleanup »

[RFC] orphan extensions cleanup

php.internals

Stas Malyshev

10 years ago
Hi! I'd like to propose an RFC to deal with extensions that currently have no maintainer: https://wiki.php.net/rfc/umaintained_extensions The main goal of the RFC is to initiate the process that by the time of 7.1 release will result in no extensions in PHP core being unmaintained. The process would be as follows: 1. Issue a call for maintainers (specific details of how, where, etc. are to be discussed, ideas welcome). 2. Wait for suitable time and hopefully find new maintainers for most or all extensions. For some stable ones not much commitment is needed beyond declaring you are willing to be responsible for them, should the need arise, for others some bugfixing may be in order :) 3. If after suitable time we can not find anybody to care enough for the extension to be responsible, move the extension from core to PECL. Please note that the ideal result is 2, not 3, but the goal is still to have no unmaintained extensions in core. Please comment and discuss! Thanks,
-- Stas Malyshev smalyshev@gmail.com

Kalle Sommer Nielsen

10 years ago
Hi Stas 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>:
> Hi! > > I'd like to propose an RFC to deal with extensions that currently have > no maintainer: > > https://wiki.php.net/rfc/umaintained_extensions
enchant: I thought Pierre maintained enchant? Despite it haven't had much real activity for years gettext WordPress can optionally use gettext for some of their po/mo files, I'm not entirely sure how this is today[1], but it might be worth taking into consideration if there are other users. pdo_dblib I have seen a few PRs here and there recently from two different guys, perhaps one of them would be interested in maintaining this as there this is the only way to connect to MSSQL from PHP (if you dislike odbc) as of PHP7, with the removal of ext/mssql. pdo_oci I have heard that maybe Oracle was going to take over this one, but it seems fairly inactive, maybe this thread can help reach out to them. readline If removed, I guess this won't affect sapi/cli? pspell Pspell should probably have been deprecated after enchant was added to the core in 5.3 I think it was, we did remove aspell infavor but pspell still remained for some reason and I think it should go too. sysvmsg / sysvshm / sysvsem We do indeed only have a category for semaphores. As a Windows guy, I cannot really make use of them, so I will wait and hear some feedback on this. tokenizer Like you mentioned, I think this should be kept in the core and possibly maintained as a part of the parser. I do write some development tools every now and then and make use of this amazing extension and will only want it to be kept. All in all, I think it is remarkable that we have 3 PDO extensions here, perhaps it will be time to reivist the whole PDO saga, but that is for another topic I guess [1] https://github.com/WordPress/WordPress/search?l=php&q=gettext&utf8=✓
-- regards, Kalle Sommer Nielsen kalle@php.net

Sebastian Bergmann

10 years ago
Am 15.08.2016 um 10:17 schrieb Kalle Sommer Nielsen:
> tokenizer > Like you mentioned, I think this should be kept in the core and > possibly maintained as a part of the parser. I do write some > development tools every now and then and make use of this amazing > extension and will only want it to be kept.
I consider this part of the core. It's (mostly) auto-generated anyway, right?

Kalle Sommer Nielsen

10 years ago
2016-08-15 10:23 GMT+02:00 Sebastian Bergmann <sebastian@php.net>:
> I consider this part of the core. It's (mostly) auto-generated anyway, right?
The token list is generated from the core using ext/tokenizer/tokenizer_data_gen.sh, rest is just to expose the two functions, so yes pretty much
-- regards, Kalle Sommer Nielsen kalle@php.net

Pierre Joye

10 years ago
On Aug 15, 2016 3:17 PM, "Kalle Sommer Nielsen" <kalle@php.net> wrote:
> > Hi Stas > > 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>: > > Hi! > > > > I'd like to propose an RFC to deal with extensions that currently have > > no maintainer: > > > > https://wiki.php.net/rfc/umaintained_extensions > > enchant: > I thought Pierre maintained enchant? Despite it haven't had much real > activity for years
Well there are not much changes in the api. And it works. So -1 here.
> gettext > WordPress can optionally use gettext for some of their po/mo files, > I'm not entirely sure how this is today[1], but it might be worth > taking into consideration if there are other users.
Here as much as I do not like it. I have to oppose it. That is a major breakage (no, pecl is not the same).

Stas Malyshev

10 years ago
Hi!
>> enchant: >> I thought Pierre maintained enchant? Despite it haven't had much real >> activity for years > > Well there are not much changes in the api. > > And it works. So -1 here.
Wait, -1 for what? Having a maintainer? How that makes sense? OK, there's no changes in API, but tomorrow comes security issue - who's going to take care of it? Would we just ship knowingly broken code then and not even tell users?
>> gettext >> WordPress can optionally use gettext for some of their po/mo files, >> I'm not entirely sure how this is today[1], but it might be worth >> taking into consideration if there are other users. > > Here as much as I do not like it. I have to oppose it. That is a major > breakage (no, pecl is not the same).
What is major breakage - having a maintainer for this extension? I'm sorry, I don't understand it.
-- Stas Malyshev smalyshev@gmail.com

Pierre Joye

10 years ago
Hi Stas, On Aug 15, 2016 11:50 PM, "Stanislav Malyshev" <smalyshev@gmail.com> wrote:
> > Hi! > > >> enchant: > >> I thought Pierre maintained enchant? Despite it haven't had much real > >> activity for years > > > > Well there are not much changes in the api. > > > > And it works. So -1 here. > > Wait, -1 for what? Having a maintainer? How that makes sense? OK, > there's no changes in API, but tomorrow comes security issue - who's > going to take care of it? Would we just ship knowingly broken code then > and not even tell users? > > >> gettext > >> WordPress can optionally use gettext for some of their po/mo files, > >> I'm not entirely sure how this is today[1], but it might be worth > >> taking into consideration if there are other users. > > > > Here as much as I do not like it. I have to oppose it. That is a major > > breakage (no, pecl is not the same). > > What is major breakage - having a maintainer for this extension? I'm > sorry, I don't understand it.
Wrong position for a reply so it may have been confusing. -1 for moving them to pecl. And enchant has a maintainer. Gettext is one of these exts without an official maintainer but still maintained, no? It is used widely as well.

Stas Malyshev

10 years ago
Hi!
> Wrong position for a reply so it may have been confusing. -1 for moving > them to pecl. And enchant has a maintainer.
Excellent. So who is the maintainer? Let's add that info to EXTENSIONS.
> Gettext is one of these exts > without an official maintainer but still maintained, no? It is used > widely as well.
If it is used widely, somebody would be able to come up as the maintainer I assume? I am not a big believer in "maintained by nobody really", because this causes things to fall between chairs. We have enough things doing this anyway, but in this case we can go to maintainer and bother him/her about it, and usually it gets things moving. Otherwise we get bystander effect. [1] [1] https://en.wikipedia.org/wiki/Bystander_effect
-- Stas Malyshev smalyshev@gmail.com

Stas Malyshev

10 years ago
Hi!
> gettext > WordPress can optionally use gettext for some of their po/mo files, > I'm not entirely sure how this is today[1], but it might be worth > taking into consideration if there are other users.
Maybe then somebody from Wordpress would be interested in taking over maintainership?
-- Stas Malyshev smalyshev@gmail.com

Adam Baratz

10 years ago
> > pdo_dblib > I have seen a few PRs here and there recently from two different guys, > perhaps one of them would be interested in maintaining this as there > this is the only way to connect to MSSQL from PHP (if you dislike > odbc) as of PHP7, with the removal of ext/mssql.
As one of those two people, it would help to have an official maintainer for this extension. The path for "something's broken" or "something should be different" to "committed fix" has been pretty murky. I'm interested in putting my name forward for this. It would help to know more about what's expected. In particular, when PRs poke at broader design questions with the extension, what's the maintainer's role? One example: https://github.com/php/php-src/pull/2017 Thanks, Adam

Kalle Sommer Nielsen

10 years ago
Hi Adam 2016-08-15 23:34 GMT+02:00 Adam Baratz <adam.baratz@gmail.com>:
> As one of those two people, it would help to have an official maintainer for > this extension. The path for "something's broken" or "something should be > different" to "committed fix" has been pretty murky.
First of all, great job on the recent pdo_dblib activity, its great to see someone is actively interested in keeping this alive.
> I'm interested in putting my name forward for this. It would help to know > more about what's expected. In particular, when PRs poke at broader design > questions with the extension, what's the maintainer's role? One example: > https://github.com/php/php-src/pull/2017
As for expectations, I think its generally expected that the maintainer oversees bugs, and future development of the extension. An example could be that a security issue is present in the extension and having someone that understands the code able to review, fix and work on it is good, instead of (like Stas mentioned), having someone look into the code without fully understanding it, and potentially breaking something else (kinda like what happened to ext/exif). As a maintainer, you are pretty much the one that oversees the extension, making sure its in working condition (to continue being in the core), having tests passes, bug reports and PRs. Ofcourse other core developers may from time to time touch the extension to fix something, and in that case make sure to double check that there is no obvious regressions (we all do make mistakes!). From seeing your past commitment to pdo_dblib, I'm a +1 keeping this extension with you as a maintainer, and I'm sure Anatol (cced) who seems to also be active in some of the PRs say yes to that too.
-- regards, Kalle Sommer Nielsen kalle@php.net

Christopher Jones

10 years ago
On 15/08/2016 6:17 PM, Kalle Sommer Nielsen wrote:
> Hi Stas > > 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>: >> Hi! >> >> I'd like to propose an RFC to deal with extensions that currently have >> no maintainer: >> >> https://wiki.php.net/rfc/umaintained_extensions >
> pdo_oci > I have heard that maybe Oracle was going to take over this one, but it > seems fairly inactive, maybe this thread can help reach out to them.
Yep. I've added myself to EXTENSIONS as PDO_OCI maintainer; can you take it out of the RFC? Thank you! Chris
-- http://twitter.com/ghrd

Stas Malyshev

10 years ago
Hi!
> I've added myself to EXTENSIONS as PDO_OCI maintainer; can you take it > out of the RFC?
Done, and thank you!
-- Stas Malyshev smalyshev@gmail.com

Johannes Schlueter

10 years ago
On Mon, 2016-08-15 at 10:17 +0200, Kalle Sommer Nielsen wrote:
> readline > If removed, I guess this won't affect sapi/cli?
It would. In 5.3 or so I moved the interactive shell to the readline extension (php -a) in order to help distributors who like to have extensions shared. I think "actual" readline functionality isn't used often in PHP, i.e. GitHub doesn't seem to have any relevant results except phpt files, syntax highlight descriptors etc. https://github.com/search?l=php&p=1&q=readline&type=Code&utf8=%E2%9C%93 If we remove the extension and move the shell part back into sapi/cli we have to teach distributors to link against readline or libedit and users won't have a way to "fix" this without recompiling complete PHP. I'm open for a discussion (probably in a different thread) about this. If needed I can do readline maintenance.
> tokenizer > Like you mentioned, I think this should be kept in the core and > possibly maintained as a part of the parser. I do write some > development tools every now and then and make use of this amazing > extension and will only want it to be kept.
The script to produce this is by me, if needed I can step in as official maintainer. A nice thing would be if we could get rid of the script and somehow generate this as part of the parser (which might mean making it part of the engine) ... johannes

Joe Watkins

9 years ago
Hi Stas, The list has been reduced since first opening the discussion, some maintainers have come forward for some of those first mentioned. There are still some outstanding extensions though, and I'd like it if we could move forward with this RFC: either finding maintainers or moving them out. Could you possibly find some time to push forward with this please ? Cheers Joe On Tue, Aug 23, 2016 at 4:44 PM, Johannes Schlüter <johannes@schlueters.de> wrote:

Nikita Popov

10 years ago
On Mon, Aug 15, 2016 at 7:53 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > I'd like to propose an RFC to deal with extensions that currently have > no maintainer: > > https://wiki.php.net/rfc/umaintained_extensions > > The main goal of the RFC is to initiate the process that by the time of > 7.1 release will result in no extensions in PHP core being unmaintained. > The process would be as follows: > > 1. Issue a call for maintainers (specific details of how, where, etc. > are to be discussed, ideas welcome). > 2. Wait for suitable time and hopefully find new maintainers for most or > all extensions. For some stable ones not much commitment is needed > beyond declaring you are willing to be responsible for them, should the > need arise, for others some bugfixing may be in order :) > 3. If after suitable time we can not find anybody to care enough for the > extension to be responsible, move the extension from core to PECL. > > Please note that the ideal result is 2, not 3, but the goal is still to > have no unmaintained extensions in core. > > Please comment and discuss! >
Is the a list of extension maintainers somewhere? As others have mentioned, tokenizer is effectively core-maintained, but if you need an explicit maintainer, you can put me in. I think the interbase extension is missing from this list, I don't think it has an active maintainer. Nikita

Kalle Sommer Nielsen

10 years ago
2016-08-15 12:41 GMT+02:00 Nikita Popov <nikita.ppv@gmail.com>:
> Is the a list of extension maintainers somewhere?
Although not updated that often, in fact I think it haven't been truly updated for years, there is php-src/EXTENSIONS. Although this information could probably be better kept in the Wiki or similar and be more up-to-date.
-- regards, Kalle Sommer Nielsen kalle@php.net

Lester Caine

10 years ago
On 15/08/16 11:41, Nikita Popov wrote:
> I think the interbase extension is missing from this list, I don't think it > has an active maintainer.
Don't go there again!
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Kalle Sommer Nielsen

10 years ago
2016-08-15 18:05 GMT+02:00 Lester Caine <lester@lsces.co.uk>:
> Don't go there again!
If there is no active maintainer, it just creates a burden on us core developers that have to maintain it to the best of our abilities if any, but there have not been anyone to take over the charge of this extension, so unless someone does now, I do not see a reason to keep this in the core. I understand that there are users of this extension, but we cannot guarantee it to be in any sort of stable working condition if there isn't anyone around to work on it. Alternatively we still have ext/pdo_firebird, which I assume will continue to work with Interbase systems. If not then I'm sorry, but I do not want another extension on our checklist if no one is willing to work on it. Same issue for ext/mssql, although in MSSQL's case we do have ext/pdo_dblib (pdo_mssql), ext/odbc & ext/pdo_odbc as an alternative. If there is someone who can actively work on it, then it can have PECL releases and if there is a big demand for it, I do not see why it cannot return to the core at a point in time it is well maintained (either extension that is)
-- regards, Kalle Sommer Nielsen kalle@php.net

Lester Caine

10 years ago
On 15/08/16 18:02, Kalle Sommer Nielsen wrote:
> 2016-08-15 18:05 GMT+02:00 Lester Caine <lester@lsces.co.uk>: >> > Don't go there again! > If there is no active maintainer, it just creates a burden on us core > developers that have to maintain it to the best of our abilities if > any, but there have not been anyone to take over the charge of this > extension, so unless someone does now, I do not see a reason to keep > this in the core. I understand that there are users of this extension, > but we cannot guarantee it to be in any sort of stable working > condition if there isn't anyone around to work on it. > > Alternatively we still have ext/pdo_firebird, which I assume will > continue to work with Interbase systems. If not then I'm sorry, but I > do not want another extension on our checklist if no one is willing to > work on it.
We will do what WE have to to maintain it, but none of us are up to speed with current PHP 'style' of coding so we also need help which is how we managed to get the PHP7 version updated. If you pull firebird then I am definitely dropping PHP7 and sticking with a working PHP5 infrastructure! PDO is no substitute for the current interbase driver and I use cross database transactions which only the generic driver can handle anyway.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Kalle Sommer Nielsen

10 years ago
2016-08-15 19:09 GMT+02:00 Lester Caine <lester@lsces.co.uk>:
> We will do what WE have to to maintain it, but none of us are up to > speed with current PHP 'style' of coding so we also need help which is > how we managed to get the PHP7 version updated.
I do not understand that statement, the last time someone actively did something to improve the extension was back in january 2015, which is portability to PHP7 and the cross Firebird support that seems to be in this extension. However I do not see any contribution or patches that helps maintain it as you so speak of, and again, I do not want that extra burden on mine or my co-contributor's shoulders having to maintain an extension none of us uses or have more in-depth knowledge about, that you must be able to understand.
>If you pull firebird > then I am definitely dropping PHP7 and sticking with a working PHP5 > infrastructure! PDO is no substitute for the current interbase driver > and I use cross database transactions which only the generic driver can > handle anyway.
I meant it can be used instead of ext/interbase, in case interbase gets removed.
-- regards, Kalle Sommer Nielsen kalle@php.net

Lester Caine

10 years ago
On 15/08/16 18:48, Kalle Sommer Nielsen wrote:
> 2016-08-15 19:09 GMT+02:00 Lester Caine <lester@lsces.co.uk>: >> We will do what WE have to to maintain it, but none of us are up to >> speed with current PHP 'style' of coding so we also need help which is >> how we managed to get the PHP7 version updated. > > I do not understand that statement, the last time someone actively did > something to improve the extension was back in january 2015, which is > portability to PHP7 and the cross Firebird support that seems to be in > this extension. However I do not see any contribution or patches that > helps maintain it as you so speak of, and again, I do not want that > extra burden on mine or my co-contributor's shoulders having to > maintain an extension none of us uses or have more in-depth knowledge > about, that you must be able to understand.
https://www.mail-archive.com/internals@lists.php.net/msg82170.html From December last year. *I* was under the impression that it was this work that was in the driver already after we had helped debug it! https://github.com/php/php-src/commits/master/ext/interbase Jan 8 commits I think ... It will be a couple of hours before my local repo is back in sync and I can verify By the way ... sql.safe_mode switch was ONLY used to lock the database selection to the one defined in the ini file. The create database block was to prevent bypassing that lock by simply creating a new database - because you could not then access that database. This IS a BC change but only if ibase.default_db is not the only database setting visible. It would have made more sense to simply move it back to the ibase ini block and document the change.
>> If you pull firebird >> then I am definitely dropping PHP7 and sticking with a working PHP5 >> infrastructure! PDO is no substitute for the current interbase driver >> and I use cross database transactions which only the generic driver can >> handle anyway. > > I meant it can be used instead of ext/interbase, in case interbase gets removed.
Since PDO is a poor substitute for any of the generic drivers it's about time THAT was finally put to bed and a decent alternative provided. Firebird/Interbase is not the only driver that needs it's generic version to provide much of the heavy lifting that PDO can't handle. Currently the interbase driver is running clean on all my compatibility testing of PHP7 so what is the problem?
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Kalle Sommer Nielsen

10 years ago
2016-08-16 0:07 GMT+02:00 Lester Caine <lester@lsces.co.uk>:
> https://www.mail-archive.com/internals@lists.php.net/msg82170.html From > December last year. *I* was under the impression that it was this work > that was in the driver already after we had helped debug it! > https://github.com/php/php-src/commits/master/ext/interbase Jan 8 > commits I think ... It will be a couple of hours before my local repo is > back in sync and I can verify
Let's take a look at the last 70 commits made to ext/interbase, which ranges from (January 3rd 2014 to now): PHP internals changes not related to the extension, including merges and other indirect changes: 61 Direct bug fixes and improvements: 9 Which is on a 2½ year commit log, that is a long time for an extension, where we have 9 open bug reports, 3 of the assigned to Mariuz, one even as old as 2009, that bug just had its 7th birthday in Jan 2016. My previous statement still stands, if there is no one to maintain this in the core, it becomes a burden on everyone else, simply because we are simply not able to maintain this code base anymore, that you must be able to see yes?
> By the way ... sql.safe_mode switch was ONLY used to lock the database > selection to the one defined in the ini file. The create database block > was to prevent bypassing that lock by simply creating a new database - > because you could not then access that database. This IS a BC change but > only if ibase.default_db is not the only database setting visible. It > would have made more sense to simply move it back to the ibase ini block > and document the change.
Yes I do realize it is a BC change, I authored the patch. But as you may also have noticed then this patch is for master only, which is PHP 7.2, that is probably first gonna be coming out in 2017 or 2018. But it is off topic, so let that be or raise your concern in another topic.
> Since PDO is a poor substitute for any of the generic drivers it's about > time THAT was finally put to bed and a decent alternative provided. > Firebird/Interbase is not the only driver that needs it's generic > version to provide much of the heavy lifting that PDO can't handle. > Currently the interbase driver is running clean on all my compatibility > testing of PHP7 so what is the problem?
The problem that we are trying to solve here is that there is no one to maintain those ways we have right now to collect to Interbase/Firebird, how are we magically gonna provide some decent alternatives if there is no one to even work on what we have in the first place? That does not even make sense.
-- regards, Kalle Sommer Nielsen kalle@php.net

Lester Caine

10 years ago
On 15/08/16 23:50, Kalle Sommer Nielsen wrote:
> The problem that we are trying to solve here is that there is no one > to maintain those ways we have right now to collect to > Interbase/Firebird, how are we magically gonna provide some decent > alternatives if there is no one to even work on what we have in the > first place? That does not even make sense.
None of the listed bugs are a problem in normal use. Some WERE fixed in previous code, but those fixes were not merged with the master code base in pre git days :( I accept that 95% of changes are due simply to generic tidies/style changes that someone feels good about and it was one of those fixes that broke a few database extensions back in PHP5.0/1 days. It took a few versions to get interbase fixed then and I did sort of understand how THAT code worked, but all the ZEND complexity now overlaying the code makes picking up simple changes a LOT more difficult. MY attempt at the PHP7 changes where simply a mess which is why *I* asked for some help working out just how to rework the code. The primary interface to firebird and interbase has not changed in 20 years so the bulk of the actions ARE only broken by PHP changes! Although it may be an advantage to finally split firebird and interbase now that FB3 is out, there is no pressing reason to do that since all one is really doing IS passing queries to the engine and getting results sets back! I should probably actually test FB3, but in my production environments there is no pressing need to use that. I'm not expecting any problems with PHP, but if the driver needs compiling with a non interbase compatible client library, THEN we need to fork firebird and if we have to do what we did when Pierre dropped support from the driver in windows builds and supply an unsupported third party build so be it ...
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Kalle Sommer Nielsen

10 years ago
2016-08-16 1:27 GMT+02:00 Lester Caine <lester@lsces.co.uk>:
> None of the listed bugs are a problem in normal use. Some WERE fixed in > previous code, but those fixes were not merged with the master code base > in pre git days :(
So you are saying that in your patch for the PHP7 support for ext/interbase, had some bugs fixed that is currently not merged into the master? I do not see any such open PRs or bug reports, or remember any such recent threads on internals about it, but now that it is being suggested we remove ext/interbase, it comes up?
> I accept that 95% of changes are due simply to generic tidies/style > changes that someone feels good about and it was one of those fixes that > broke a few database extensions back in PHP5.0/1 days. It took a few > versions to get interbase fixed then and I did sort of understand how > THAT code worked, but all the ZEND complexity now overlaying the code > makes picking up simple changes a LOT more difficult. MY attempt at the > PHP7 changes where simply a mess which is why *I* asked for some help > working out just how to rework the code. The primary interface to > firebird and interbase has not changed in 20 years so the bulk of the > actions ARE only broken by PHP changes! Although it may be an advantage > to finally split firebird and interbase now that FB3 is out, there is no > pressing reason to do that since all one is really doing IS passing > queries to the engine and getting results sets back!
The Zend API is not that complex for extensions, it have not changed too much. We have tons of extensions now at least, or had in the PHP7 development time that could be used as a base understanding of how simple APIs are working. We also have an IRC channel that we use where you can probably get some support too, or even StackOverflow's chat might be of some help, heck even Twitter. But I still fail to understand the point you are making, at first you are talking about "WE" as being who? Us, the PHP Development Team? You and your company? The Community? The baseline is fairly simple, and I will try to say it as directly as I can hopefully one last time; We cannot maintain an extension if there is no one willing to step forward to work on it, someone who understands its internals, have proper testing facilities and such, if that is the case, which seems to have been for a semi long time for Interbase, then it should *NOT* be in the core. If there is no one to maintain it, and there are security issues in it, then it causes even more problems for us, the PHP Development Team, if we continue to redistribute the core PHP interpreter with an extension that can potentially compromise a server, I'm not talking strictly about Interbase, as I do not have the in-depth knowledge about it, but I'm talking aboustract, whether its Interbase, BCMath or something third.
> I should probably actually test FB3, but in my production environments > there is no pressing need to use that. I'm not expecting any problems > with PHP, but if the driver needs compiling with a non interbase > compatible client library, THEN we need to fork firebird and if we have > to do what we did when Pierre dropped support from the driver in windows > builds and supply an unsupported third party build so be it ...
If Pierre dropped support for a driver on Windows, there is probably a good reason to do so. On the top of my mind, I can think of several reasons why it could be a problem. Unsupported library, commercial tools required, unsupported Windows version, ... the list goes on. But a piece of advice, if you are so keen on keeping Interbase, and the "WE" you are so often talking about, why do you not contribute to the Core to see it keep its place? If its an internals support issue, then we have some, although rough snippets on the wiki[1], the PHP.net manual[2], The PHP Internals Book[3], Nikita also have some interesting and in depth reads on his blog[4]. Although I do not know how updated these are to PHP7, but it does give you some hints of where to look for things and what to keep in mind, and in worst case, then go to the source. [1] https://wiki.php.net/internals [2] http://php.net/internals2.ze1.zendapi [3] http://www.phpinternalsbook.com/ [4] https://nikic.github.io/
-- regards, Kalle Sommer Nielsen kalle@php.net

Christoph Becker

10 years ago
On 15.08.2016 at 07:53, Stanislav Malyshev wrote:
> I'd like to propose an RFC to deal with extensions that currently have > no maintainer: > > https://wiki.php.net/rfc/umaintained_extensions > > The main goal of the RFC is to initiate the process that by the time of > 7.1 release will result in no extensions in PHP core being unmaintained. > The process would be as follows: > > 1. Issue a call for maintainers (specific details of how, where, etc. > are to be discussed, ideas welcome). > 2. Wait for suitable time and hopefully find new maintainers for most or > all extensions. For some stable ones not much commitment is needed > beyond declaring you are willing to be responsible for them, should the > need arise, for others some bugfixing may be in order :) > 3. If after suitable time we can not find anybody to care enough for the > extension to be responsible, move the extension from core to PECL. > > Please note that the ideal result is 2, not 3, but the goal is still to > have no unmaintained extensions in core. > > Please comment and discuss!
Thanks for your work on this RFC! :-) Generally, I'm all for moving unmaintained extensions to PECL. However, I wonder on what information the concrete selection of unmaintained extensions in the RFC is based. If it is php-src/EXTENSIONS, the RFC is moot, in my opinion, as this file is grossly out-dated. It seems that at least a third of the maintainers listed there have been inactive for years. For instance, Stefan is claimed to be the maintainer of ftp, but his most recent commit to this extension appears to be from 2002. (No complaint, just an observation.) Another example is sqlite3, where Scott's most recent commit has been 5 years ago. Yet another example: Marcus's most recent commit to simplexml is from 2008. As final example I mention bcmath, where Andi has made his most recent commit 2004. Again, I don't complain that the maintainers are inactive (what is absolutely fine for me), but rather that php-src/EXTENSIONS is totally out-dated. The bug tracker statistics appear to present a somewhat more realistic view: <https://bugs.php.net/stats.php>. The topmost bundled extensions having the most unresolved issues are standard, soap, date, spl and pdo. The XML related extensions (libxml, dom, simplexml, xml, etc.) also sum up.
-- Christoph M. Becker

Stas Malyshev

10 years ago
Hi!
> Generally, I'm all for moving unmaintained extensions to PECL. > However, I wonder on what information the concrete selection of > unmaintained extensions in the RFC is based. If it is > php-src/EXTENSIONS, the RFC is moot, in my opinion, as this file is > grossly out-dated. It seems that
I don't see how it makes it moot, unless that means we actually have maintainers for all the extensions but we don't know it. In which case, I think RFC is successful, even if leads to just updating EXTENSIONS. And since we don't really have anything else, at least for now, we would go with the best info we have. As you can see, there's also a need for updating EXTENSIONS and figuring out if the listed maintainers are indeed still active, which will be topic of the followup RFC.
> Again, I don't complain that the maintainers are inactive (what is > absolutely fine for me), but rather that php-src/EXTENSIONS is > totally out-dated.
True, but that only makes the maintainership status update *more* necessary, not less.
> The bug tracker statistics appear to present a somewhat more > realistic view: <https://bugs.php.net/stats.php>. The topmost > bundled extensions having the most unresolved issues are standard, > soap, date, spl and pdo. The XML related extensions (libxml, dom, > simplexml, xml, etc.) also sum up.
The problem is not a sheer number of issues, but the question of if there's anybody to take care of them, especially the important ones. E.g. I've had to deal with wddx and exif issues, even though I don't know both formats well enough - because otherwise we'd have security bugs sitting there for a long time. Also we have security issues in mysql that nobody is taking care of, and in FTP, and in libxml, and in FPM, and in other places.
-- Stas Malyshev smalyshev@gmail.com

Christoph Becker

10 years ago
Hi! On 15.08.2016 at 18:46, Stanislav Malyshev wrote:
>> Generally, I'm all for moving unmaintained extensions to PECL. >> However, I wonder on what information the concrete selection of >> unmaintained extensions in the RFC is based. If it is >> php-src/EXTENSIONS, the RFC is moot, in my opinion, as this file is >> grossly out-dated. It seems that > > I don't see how it makes it moot, unless that means we actually have > maintainers for all the extensions but we don't know it. In which case, > I think RFC is successful, even if leads to just updating EXTENSIONS. > And since we don't really have anything else, at least for now, we would > go with the best info we have.
That was badly worded from me. Actually, I didn't mean to say the RFC generally is moot, but rather that the selection of extensions is moot (in my opinion), because it is based on wrong assumptions.
> As you can see, there's also a need for updating EXTENSIONS and figuring > out if the listed maintainers are indeed still active, which will be > topic of the followup RFC.
Maybe it would be better to first check the current status quo of maintainership, and after that taking care of the insufficiently maintained extensions. It should be easy to verify whether the maintainers are still interested in maintaining the respective extension(s); just write them an email and ask. If somebody doesn't answer in due time, we also have an answer.
>> The bug tracker statistics appear to present a somewhat more >> realistic view: <https://bugs.php.net/stats.php>. The topmost >> bundled extensions having the most unresolved issues are standard, >> soap, date, spl and pdo. The XML related extensions (libxml, dom, >> simplexml, xml, etc.) also sum up. > > The problem is not a sheer number of issues, but the question of if > there's anybody to take care of them, especially the important ones. > E.g. I've had to deal with wddx and exif issues, even though I don't > know both formats well enough - because otherwise we'd have security > bugs sitting there for a long time. Also we have security issues in > mysql that nobody is taking care of, and in FTP, and in libxml, and in > FPM, and in other places.
Okay, the situation wrt. private bug reports is rather special, as you've already pointed out in the other mail "rethinking security issues in bugs db". Unless the extension maintainer has access to these tickets, (s)he can't be of much help.
-- Christoph M. Becker

Stas Malyshev

10 years ago
Hi!
> Maybe it would be better to first check the current status quo of > maintainership, and after that taking care of the insufficiently > maintained extensions.
I think we can do both in parallel. I'll try to write the second RFC soon (hopefully I'll have time) and we can do the maintainer list refersh together with deciding what to do with unmaintaned extensions.
-- Stas Malyshev smalyshev@gmail.com

Christoph Becker

10 years ago
Hi! On 15.08.2016 at 22:39, Stanislav Malyshev wrote:
>> Maybe it would be better to first check the current status quo of >> maintainership, and after that taking care of the insufficiently >> maintained extensions. > > I think we can do both in parallel. I'll try to write the second RFC > soon (hopefully I'll have time) and we can do the maintainer list > refersh together with deciding what to do with unmaintaned extensions.
Sounds good to me. If I can be of assistance, please let me know.
-- Christoph M. Becker

Kalle Sommer Nielsen

10 years ago
Hi 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>:
> Please comment and discuss!
What about adding the following: ext/dba ext/interbase ext/recode I tried to look for anything recode, but it seems far gone, although I did not do an extensive search for it. I'm unsure about the usage though, but I doubt it can be much, considering we got iconv. As for DBA, this extension have not really seen any major updates or anything since 2009 when the Tokyo Cabinet support was added (PHP 5.3), is this still used largely or? Interbase have already been discussed a fair bit in this thread, and it does not seem Leister is going to contribute despite being the only one around interested in this one, at least here on internals@.
-- regards, Kalle Sommer Nielsen kalle@php.net

Daniel Morris

10 years ago
Interbase would be much better existing in PECL, since there is no interest in supporting it by internals. Couchbase and Cassandra both exist in PECL and both of those are likely more widely used by the community than Interbase, and both are also still maintained (with commits as recently as this month.)
-- Daniel Morris daniel@honestempire.com On Thu, 18 Aug 2016, at 12:32 AM, Kalle Sommer Nielsen wrote:

Lester Caine

10 years ago
On 18/08/16 01:02, Daniel Morris wrote:
> both of those are likely more widely used by the > community than Interbase,
Can you justify that statement! I'd add that PHP5.2/3 is more widely used that PHP7 ... And as already said it's not that we don't want to maintain it, it's that we have no one who is competent enough to maintain it.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Daniel Morris

10 years ago
On Thu, 18 Aug 2016, at 06:58 AM, Lester Caine wrote:
> Can you justify that statement!
A quick comparison on Google Trends will show this, since the beginning of 2013 Couchbase has been more popular, GitHub also has more PHP projects for Couchbase than Interbase. On Thu, 18 Aug 2016, at 06:58 AM, Lester Caine wrote:
> I'd add that PHP5.2/3 is more widely used that PHP7 ...
Interbase will continue to exist 5.{2,3,4,5,6}, and as you're not really keen to upgrade (30% of your clients are still on 5.2, despite it reaching end of life over five years ago, and 5.3 reached end of life 2 years ago), removing it from PHP7 shouldn't cause you too much concern, since (based on your current pace of upgrading) you won't be switching to PHP7 until 2024.
-- Daniel Morris daniel@honestempire.com

Lester Caine

10 years ago
On 18/08/16 08:08, Daniel Morris wrote:
> On Thu, 18 Aug 2016, at 06:58 AM, Lester Caine wrote: >> Can you justify that statement! > > A quick comparison on Google Trends will show this, since the beginning > of 2013 Couchbase has been more popular, GitHub also has more PHP > projects for Couchbase than Interbase.
Well Github figures are a problem where Hg is more popular amongst Firebird users and financial services secure systems tend not to publish their use of code at all. Firebird is used as a free alternative to Oracle in many large services and at one time Interbase ran much of the US emergency services - until Borland decided to end of life it in 1999. For some reason they did not know just how important Interbase was to many people :(
> On Thu, 18 Aug 2016, at 06:58 AM, Lester Caine wrote: >> I'd add that PHP5.2/3 is more widely used that PHP7 ... > > Interbase will continue to exist 5.{2,3,4,5,6}, and as you're not really > keen to upgrade (30% of your clients are still on 5.2, despite it > reaching end of life over five years ago, and 5.3 reached end of life 2 > years ago), removing it from PHP7 shouldn't cause you too much concern, > since (based on your current pace of upgrading) you won't be switching > to PHP7 until 2024.
http://php7.lsces.org.uk/ and Firebird is running fine! The problem with bringing PHP5.2/3 users forward is that nobody can be bothered to help them. I simply don't have enough time to move the clients I HAVE got over and I've now stopped taking any more of that business on simply because there are not enough hours in the day. NOW it looks like I have to find time to keep the C side of things working as well ... something that is a lot easier for someone who knows WHY they are changing the way something works inside PHP as happened with PHP7. Firebird did not change so the client library is still the same! Even moving the sites that I HAVE already pulled up to PHP5.6 over to PHP7 requires additional work and testing so I resent your suggestion that I'm taking too long doing all this work. Perhaps it is time to give up even trying to help PHP!
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Kalle Sommer Nielsen

10 years ago
2016-08-18 9:46 GMT+02:00 Lester Caine <lester@lsces.co.uk>:
> Well Github figures are a problem where Hg is more popular amongst > Firebird users and financial services secure systems tend not to publish > their use of code at all. Firebird is used as a free alternative to > Oracle in many large services and at one time Interbase ran much of the > US emergency services - until Borland decided to end of life it in 1999. > For some reason they did not know just how important Interbase was to > many people :( > > <snip> > > The problem with bringing PHP5.2/3 users forward is that nobody can be > bothered to help them. I simply don't have enough time to move the > clients I HAVE got over and I've now stopped taking any more of that > business on simply because there are not enough hours in the day. NOW it > looks like I have to find time to keep the C side of things working as > well ... something that is a lot easier for someone who knows WHY they > are changing the way something works inside PHP as happened with PHP7. > Firebird did not change so the client library is still the same! > > Even moving the sites that I HAVE already pulled up to PHP5.6 over to > PHP7 requires additional work and testing so I resent your suggestion > that I'm taking too long doing all this work. Perhaps it is time to give > up even trying to help PHP!
Honestly Lester, I do enjoy a good morning read but I'm getting a little tired of this; this have no relevance to the extensions maintainers. I already understood in your first mail (and all other mails sent to internals@) that interbase/firebird is important to you, I get that. But the problem at hand is rather different, this is how we, we as in the Core Developers of PHP, handle extensions that we give the proper support and maintenance as Rowan pointed out, our current promise is pretty much a lie since we cannot give extensions in the core, the support they may need. It is not like (as also pointed out), that the code will go away and vanish, it will still be in PECL, and with a PECL release DLLs will still be compiled for download if you like me, use Windows. But I kinda expect this to be the end of the off-topic, I'm so tired that we always end up on a diverted path and would much rather want to see some more interest in our core extensions.
-- regards, Kalle Sommer Nielsen kalle@php.net

Christoph Becker

10 years ago
On 18.08.2016 at 01:32, Kalle Sommer Nielsen wrote:
> 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>: >> Please comment and discuss! > > What about adding the following: > ext/dba > > As for DBA, this extension have not really seen any major updates or > anything since 2009 when the Tokyo Cabinet support was added (PHP > 5.3), is this still used largely or?
I don't know, but most certainly not on Windows. I had a look at ext/dba, because I like that we have it bundled, but got 3 failing tests (flatfile and inifile), which might be caused by running in a Vagrant box on NTFS. So I tried to compile on Windows, just to learn that config.w32 is totally out-dated. It doesn't support individual config options for the different drivers, but rather checks whether db3 is found, and only then configures the built in drivers. Of course, db3 is not part of the delivered deps, what is likely the reason that dba_php.dll isn't distributed anymore as of PHP 5.3 (it would make sense, IMO, to ship dba_php.dll with the built-in drivers plus those whose requirements could be bundled in the deps). Fixing config.w32 shouldn't be too hard (it may take quite some time to test with the different drivers, though), but I expect further issues would have to be solved. Besides some unresolved bugs[1], for instance, it still uses zend_get_parameters_array_ex() at least once[2], even though this API has been deprecated as of PHP 7.0.0. [1] <https://bugs.php.net/search.php?cmd=display&package_name[]=DBM%2FDBA+related> [2] <https://github.com/php/php-src/blob/PHP-7.0.9/ext/dba/dba.c#L654>
-- Christoph M. Becker

Kalle Sommer Nielsen

10 years ago
Hi 2016-08-18 15:03 GMT+02:00 Christoph M. Becker <cmbecker69@gmx.de>:
> I don't know, but most certainly not on Windows. I had a look at > ext/dba, because I like that we have it bundled, but got 3 failing tests > (flatfile and inifile), which might be caused by running in a Vagrant > box on NTFS. So I tried to compile on Windows, just to learn that > config.w32 is totally out-dated. It doesn't support individual config > options for the different drivers, but rather checks whether db3 is > found, and only then configures the built in drivers. Of course, db3 is > not part of the delivered deps, what is likely the reason that > dba_php.dll isn't distributed anymore as of PHP 5.3 (it would make > sense, IMO, to ship dba_php.dll with the built-in drivers plus those > whose requirements could be bundled in the deps). > > Fixing config.w32 shouldn't be too hard (it may take quite some time to > test with the different drivers, though), but I expect further issues > would have to be solved. Besides some unresolved bugs[1], for instance, > it still uses zend_get_parameters_array_ex() at least once[2], even > though this API has been deprecated as of PHP 7.0.0.
Hmm interesting, I can try take a look once I'm at home again. Extensions that can support more features in newer versions and such are usually not checked on Windows, as unlike m4 files we do not compile check for symbols and such and assume a certain version as minimum, but with the low targeted audience we have that builds PHP on their on, this is not an issue. We do have win32/libs.txt I think that lists the libs we use for distro builds. But I will have to look at our deps and see if it is possible to get this running again with some cross reference to the m4. As for zend_get_parameters_array_ex() usage, this should be a no brainer quick fix.
> [1] > <https://bugs.php.net/search.php?cmd=display&package_name[]=DBM%2FDBA+related> > [2] <https://github.com/php/php-src/blob/PHP-7.0.9/ext/dba/dba.c#L654>
-- regards, Kalle Sommer Nielsen kalle@php.net

Christoph Becker

10 years ago
Hi Kalle! On 18.08.2016 at 15:12, Kalle Sommer Nielsen wrote:
> 2016-08-18 15:03 GMT+02:00 Christoph M. Becker <cmbecker69@gmx.de>: > >> I don't know, but most certainly not on Windows. I had a look at >> ext/dba, because I like that we have it bundled, but got 3 failing tests >> (flatfile and inifile), which might be caused by running in a Vagrant >> box on NTFS. So I tried to compile on Windows, just to learn that >> config.w32 is totally out-dated. It doesn't support individual config >> options for the different drivers, but rather checks whether db3 is >> found, and only then configures the built in drivers. Of course, db3 is >> not part of the delivered deps, what is likely the reason that >> dba_php.dll isn't distributed anymore as of PHP 5.3 (it would make >> sense, IMO, to ship dba_php.dll with the built-in drivers plus those >> whose requirements could be bundled in the deps). > > Hmm interesting, I can try take a look once I'm at home again. > Extensions that can support more features in newer versions and such > are usually not checked on Windows, as unlike m4 files we do not > compile check for symbols and such and assume a certain version as > minimum, but with the low targeted audience we have that builds PHP on > their on, this is not an issue. We do have win32/libs.txt I think that > lists the libs we use for distro builds.
You probably mean win32/build/libs_version.txt (I wasn't aware of this file; thanks!). AFAICS, none of the external dba drivers are already there, and the DB 3-5 binaries can't probably be added due to legal issues.
> But I will have to look at our deps and see if it is possible to get > this running again with some cross reference to the m4.
That would be great! A quick fix (simply removing the db3 check) made it compile, but the test suite stalled on dba_flatfile.phpt. Apparantly, there are issues regarding mode 'n' on Windows/NTFS.
> As for zend_get_parameters_array_ex() usage, this should be a no > brainer quick fix.
Indeed. I've noted that only, because it shows that the extension is not actively maintained (otherwise the maintainer would almost certainly have noticed the deprecation warning and fixed it right away).
-- Christoph M. Becker

Christoph Becker

10 years ago
On 18.08.2016 at 15:46, Christoph M. Becker wrote:
> That would be great! A quick fix (simply removing the db3 check) made > it compile, but the test suite stalled on dba_flatfile.phpt.
That was actually caused by the test case being broken. I've fixed it just now: <http://git.php.net/?p=php-src.git;a=commit;h=bc1214f2>. The test is (still) failing, though.
-- Christoph M. Becker

Christoph Becker

10 years ago
On 18.08.2016 at 15:46, Christoph M. Becker wrote:
> On 18.08.2016 at 15:12, Kalle Sommer Nielsen wrote: > >> But I will have to look at our deps and see if it is possible to get >> this running again with some cross reference to the m4. > > That would be great!
I have just committed the minimal changes to be able to build dba on Windows without libdb, see <http://git.php.net/?p=php-src.git;a=commit;h=ad76e8a5>.
-- Christoph M. Becker

Pierre Joye

10 years ago
On Aug 18, 2016 8:03 PM, "Christoph M. Becker" <cmbecker69@gmx.de> wrote:
> > On 18.08.2016 at 01:32, Kalle Sommer Nielsen wrote: > > > 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>: > >> Please comment and discuss! > > > > What about adding the following: > > ext/dba > > > > As for DBA, this extension have not really seen any major updates or > > anything since 2009 when the Tokyo Cabinet support was added (PHP > > 5.3), is this still used largely or? > > I don't know, but most certainly not on Windows. I had a look at > ext/dba, because I like that we have it bundled, but got 3 failing tests > (flatfile and inifile), which might be caused by running in a Vagrant > box on NTFS. So I tried to compile on Windows, just to learn that > config.w32 is totally out-dated. It doesn't support individual config > options for the different drivers, but rather checks whether db3 is > found, and only then configures the built in drivers. Of course, db3 is > not part of the delivered deps, what is likely the reason that > dba_php.dll isn't distributed anymore as of PHP 5.3 (it would make > sense, IMO, to ship dba_php.dll with the built-in drivers plus those > whose requirements could be bundled in the deps). > > Fixing config.w32 shouldn't be too hard (it may take quite some time to > test with the different drivers, though), but I expect further issues > would have to be solved.
The last time I checked it was for the 5.3 windows support big jump. If I remember correctly many banckends were not available on windowd (mainly vc6). Some may be available now.

Anatol Belski

10 years ago
Hi Pierre,
> -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Friday, August 19, 2016 1:00 PM > To: Christoph Becker <cmbecker69@gmx.de> > Cc: PHP internals <internals@lists.php.net>; Kalle Sommer Nielsen > <kalle@php.net>; Stanislav Malyshev <smalyshev@gmail.com> > Subject: Re: [PHP-DEV] [RFC] orphan extensions cleanup > > On Aug 18, 2016 8:03 PM, "Christoph M. Becker" <cmbecker69@gmx.de> > wrote: > > > > On 18.08.2016 at 01:32, Kalle Sommer Nielsen wrote: > > > > > 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>: > > >> Please comment and discuss! > > > > > > What about adding the following: > > > ext/dba > > > > > > As for DBA, this extension have not really seen any major updates or > > > anything since 2009 when the Tokyo Cabinet support was added (PHP > > > 5.3), is this still used largely or? > > > > I don't know, but most certainly not on Windows. I had a look at > > ext/dba, because I like that we have it bundled, but got 3 failing > > tests (flatfile and inifile), which might be caused by running in a > > Vagrant box on NTFS. So I tried to compile on Windows, just to learn > > that > > config.w32 is totally out-dated. It doesn't support individual config > > options for the different drivers, but rather checks whether db3 is > > found, and only then configures the built in drivers. Of course, db3 > > is not part of the delivered deps, what is likely the reason that > > dba_php.dll isn't distributed anymore as of PHP 5.3 (it would make > > sense, IMO, to ship dba_php.dll with the built-in drivers plus those > > whose requirements could be bundled in the deps). > > > > Fixing config.w32 shouldn't be too hard (it may take quite some time > > to test with the different drivers, though), but I expect further > > issues would have to be solved. > > The last time I checked it was for the 5.3 windows support big jump. > > If I remember correctly many banckends were not available on windowd (mainly > vc6). Some may be available now.
I was checking for possible libs after Christoph's enablement commit last week. At least qdbm looks like possible to be supported. The bundled libcdb is quite old. There are no new releases, but some patches might be available, need to check. Some Tokyo Cabinet ports did exist, but again need research. Closer to the end of the year, time could be taken to do the research and tests, so maybe to support more of dba in 7.2. Regards Anatol

Christoph Becker

10 years ago
On 22.08.2016 at 18:52, Anatol Belski wrote:
> Hi Pierre, > >> -----Original Message----- >> From: Pierre Joye [mailto:pierre.php@gmail.com] >> Sent: Friday, August 19, 2016 1:00 PM >> To: Christoph Becker <cmbecker69@gmx.de> >> Cc: PHP internals <internals@lists.php.net>; Kalle Sommer Nielsen >> <kalle@php.net>; Stanislav Malyshev <smalyshev@gmail.com> >> Subject: Re: [PHP-DEV] [RFC] orphan extensions cleanup >> >> On Aug 18, 2016 8:03 PM, "Christoph M. Becker" <cmbecker69@gmx.de> >> >>> I don't know, but most certainly not on Windows. I had a look at >>> ext/dba, because I like that we have it bundled, but got 3 failing >>> tests (flatfile and inifile), which might be caused by running in a >>> Vagrant box on NTFS. So I tried to compile on Windows, just to learn >>> that >>> config.w32 is totally out-dated. >> >> The last time I checked it was for the 5.3 windows support big jump. >> >> If I remember correctly many banckends were not available on windowd (mainly >> vc6). Some may be available now. > > I was checking for possible libs after Christoph's enablement commit > last week. At least qdbm looks like possible to be supported. The > bundled libcdb is quite old. There are no new releases, but some > patches might be available, need to check. Some Tokyo Cabinet ports > did exist, but again need research. Closer to the end of the year, > time could be taken to do the research and tests, so maybe to support > more of dba in 7.2.
That would be great! gdbm shouldn't also be a problem, if we can build that ourselves. But perhaps most important would be Oracle DB. As config.w32 is now, only libdb31s and libdb61 are supported. Anyhow, it might be best not to hijack this thread further, but instead move the discussion to internals-win. :-)
-- Christoph M. Becker

Christoph Becker

8 years ago
Hi Stas! On 15.08.2016 at 07:53, Stanislav Malyshev wrote:
> I'd like to propose an RFC to deal with extensions that currently have > no maintainer: > > https://wiki.php.net/rfc/umaintained_extensions > > The main goal of the RFC is to initiate the process that by the time of > 7.1 release will result in no extensions in PHP core being unmaintained. > The process would be as follows: > > 1. Issue a call for maintainers (specific details of how, where, etc. > are to be discussed, ideas welcome). > 2. Wait for suitable time and hopefully find new maintainers for most or > all extensions. For some stable ones not much commitment is needed > beyond declaring you are willing to be responsible for them, should the > need arise, for others some bugfixing may be in order :) > 3. If after suitable time we can not find anybody to care enough for the > extension to be responsible, move the extension from core to PECL. > > Please note that the ideal result is 2, not 3, but the goal is still to > have no unmaintained extensions in core.
I think it is *very* important to finally tackle this topic. Since it is rather late for actually moving several extensions to PECL for PHP 7.3, and since this would be an ongoing process anyway, I suggest to turn the RFC into a general RFC regarding “Process and Policy” – basically, to decide on clear rules regarding maintainership of extensions and moving of orphaned extensions to PECL. Individual extensions could than be handled without the need for much discussion and be resolved with a simple RFC/voting (or maybe even without).
-- Christoph M. Becker

Sara Golemon

8 years ago
On Tue, Jun 12, 2018 at 7:54 AM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> I think it is *very* important to finally tackle this topic. Since it > is rather late for actually moving several extensions to PECL for PHP > 7.3, and since this would be an ongoing process anyway, I suggest to > turn the RFC into a general RFC regarding “Process and Policy” – > basically, to decide on clear rules regarding maintainership of > extensions and moving of orphaned extensions to PECL. Individual > extensions could than be handled without the need for much discussion > and be resolved with a simple RFC/voting (or maybe even without). >
Hear! Hear! Per issue #1, I'd suggest an OWNERS file per ext/*/ dir with names and year ranges. Continued ownership demarked by explicitly incrementing the end year BY THE MAINTAINER. An extension is considered abandoned if the end year is not updated by the following January. Example: ext/hash/OWNER might contain "pollita 2005-2018" (and other entries). 2019 rolls around, even if it's December and I haven't updated the end year, it's still not considered abandoned until January 2020. This leaves the second half of a year for auditing "soon to be adandoned" exts and reach out to current "owners" and/or find potential replacements for the following year. I'd also suggest that this information is read in by bugs.php.net so that extension owners can make easy dashboards from their relevant bugs, but that's not really related to this RFC topic beyond deciding on a file format (maybe JSON?) I 100% agree that #3 is the least ideal option and should be avoided wherever possible. It requires that literally nobody GAF about the extension AND that we're unable to recruit support from outside users. I think removal of dead extensions which have no immediate replacement should come with a public notice period. Posts on high traffic sites such as Reddit and headers added to relevant chapter(s) of the manual for example. If this gets us some developer at a company who relies on the extension but never considered Open Source as a viable track, then we've won twice. I do say "which have no immediate replacement" because I don't think we'd need a public notice for something like the removal of mysql or mcrypt as they both had strong viable alternatives. Similar if we ever decide to replace ext/gmp with github.com/sgolemon/gmpi extension (shameless plug). -Sara

Christoph Becker

8 years ago
On 12.06.2018 at 16:15, Sara Golemon wrote:
> Per issue #1, I'd suggest an OWNERS file per ext/*/ dir with names and > year ranges. Continued ownership demarked by explicitly incrementing > the end year BY THE MAINTAINER. An extension is considered abandoned > if the end year is not updated by the following January. Example: > ext/hash/OWNER might contain "pollita 2005-2018" (and other entries). > 2019 rolls around, even if it's December and I haven't updated the end > year, it's still not considered abandoned until January 2020. This > leaves the second half of a year for auditing "soon to be adandoned" > exts and reach out to current "owners" and/or find potential > replacements for the following year.
I'm afraid this might be misused. It's too easy to update the year number, without actually doing *any* real maintenance work (“I'll come back to that later” …). Some automated process would be nice, but manually checking the bug tracker for maintenance work (particularly wrt. security issues), and/or the commit log seems to be okay for now.
-- Christoph M. Becker

Rowan Collins

8 years ago
On 12 June 2018 at 16:01, Christoph M. Becker <cmbecker69@gmx.de <mailto:cmbecker69@gmx.de>> wrote: I'm afraid this might be misused.  It's too easy to update the year number, without actually doing *any* real maintenance work (“I'll come back to that later” …).  Some automated process would be nice, but manually checking the bug tracker for maintenance work (particularly wrt. security issues), and/or the commit log seems to be okay for now. That sounds like you're looking for a technical solution to an organisational / social problem: if someone lists themselves as a maintainer, they are making a commitment to volunteer their effort. That commitment could be defined somewhere if it's not already, but it's never going to be an automatically measurable SLA. It might be useful to have tools to help monitor - e.g. a dashboard that runs a couple of queries to give an idea of recent activity on each extension - but there's always going to be a judgement call. What if some helpful volunteer raises 100 bugs, and only the 10 most serious of them are fixed within a release cycle; is the maintainer failing to keep up, or are they correctly triaging and prioritising? What if a security issue is raised, but there's no clear fix? No statistic will give you a true view of the effort a maintainer has put into trying. So the important thing there is what is the policy: who gets to decide that a maintainer is not fulfilling their commitment, and what is the process for officially removing them? If someone else wants to take over maintainership, that may be as simple as "would you like me to help?"; but if it's a case of marking an extension unmaintained, it could be controversial. The problem Sara's suggestion fixes is different: right now, maintainers make a commitment once, for an indeterminate amount of time. By periodically making a change, maintainers are simply saying "yes, I am still interested in maintaining this extension", in a format that can be easily reported on. I think this is a useful concept, and the timeline could be linked to the annual release cycle; for instance: - if the last promise in the OWNER file is over a year old at time of Alpha, check if they are still interested, and seek a new maintainer if not - if it is still not updated by RC, mark the extension as pending removal - if it is still unclaimed by the *next* alpha (i.e. a year later), remove it from core Regards,
-- Rowan Collins [IMSoP]

Stas Malyshev

8 years ago
Hi!
>    I'm afraid this might be misused.  It's too easy to update the year >    number, without actually doing *any* real maintenance work (“I'll come >    back to that later” …).  Some automated process would be nice, but >    manually checking the bug tracker for maintenance work (particularly >    wrt. security issues), and/or the commit log seems to be okay for now. > > > > That sounds like you're looking for a technical solution to an > organisational / social problem: if someone lists themselves as a > maintainer, they are making a commitment to volunteer their effort. That > commitment could be defined somewhere if it's not already, but it's > never going to be an automatically measurable SLA.
I agree here. If somebody cares enough to update the number, and by that commit to maintainership, this is already more than halfway towards the solution. We can never force anyone to be an active maintainer, or to allocate specific amount of time to fixing bugs or develop features, but the problem now is that we don't even have anybody in any maintainership capacity. We've had some people listed that haven't been active for years, and just remain there by default. I think once we solve this problem and have explicit commitment from maintainers, the question of how to make this commitment turn into a real work will be much better problem to have. We will still have to deal with it, obviously, but I think we first have to even get there.
-- Stas Malyshev smalyshev@gmail.com

Christoph Becker

8 years ago
On 12.06.2018 at 23:33, Stanislav Malyshev wrote:
>>> I'm afraid this might be misused.  It's too easy to update the year >>> number, without actually doing *any* real maintenance work (“I'll come >>> back to that later” …).  Some automated process would be nice, but >>> manually checking the bug tracker for maintenance work (particularly >>> wrt. security issues), and/or the commit log seems to be okay for now. >> >> That sounds like you're looking for a technical solution to an >> organisational / social problem: if someone lists themselves as a >> maintainer, they are making a commitment to volunteer their effort. That >> commitment could be defined somewhere if it's not already, but it's >> never going to be an automatically measurable SLA. > > I agree here. If somebody cares enough to update the number, and by that > commit to maintainership, this is already more than halfway towards the > solution. We can never force anyone to be an active maintainer, or to > allocate specific amount of time to fixing bugs or develop features, but > the problem now is that we don't even have anybody in any maintainership > capacity. We've had some people listed that haven't been active for > years, and just remain there by default. I think once we solve this > problem and have explicit commitment from maintainers, the question of > how to make this commitment turn into a real work will be much better > problem to have. We will still have to deal with it, obviously, but I > think we first have to even get there.
Okay, you've convinced me. :)
-- Christoph M. Becker

Stas Malyshev

8 years ago
Hi!
> Per issue #1, I'd suggest an OWNERS file per ext/*/ dir with names and > year ranges. Continued ownership demarked by explicitly incrementing > the end year BY THE MAINTAINER. An extension is considered abandoned > if the end year is not updated by the following January. Example:
Makes sense. Note that abandoned in itself does not mean it will be moved out - but it is certainly a base for a call for maintainership and the discussion of We could also initialize this list with the date of the latest commit or bug response from the official current maintainer.
> I think removal of dead extensions which have no immediate replacement > should come with a public notice period. Posts on high traffic sites > such as Reddit and headers added to relevant chapter(s) of the manual > for example. If this gets us some developer at a company who relies > on the extension but never considered Open Source as a viable track, > then we've won twice. I do say "which have no immediate replacement"
Sounds like a good idea. If you'd like, please feel free to edit the RFC to add a section about public notice procedure before moving. Otherwise, we could just make the procedure separately, it doesn't *have* to be part of the RFC.
> because I don't think we'd need a public notice for something like the > removal of mysql or mcrypt as they both had strong viable > alternatives. Similar if we ever decide to replace ext/gmp with > github.com/sgolemon/gmpi extension (shameless plug).
Sure, if we just replace a thing with a better thing, there's no point to look for a maintainer for the inferior thing.
-- Stas Malyshev smalyshev@gmail.com

Stas Malyshev

8 years ago
Hi!
> I think it is *very* important to finally tackle this topic. Since > it is rather late for actually moving several extensions to PECL for > PHP 7.3, and since this would be an ongoing process anyway, I suggest > to
I'm not sure it's too late for 7.3. If we see that the extension is unmaintained, we could move it out for 7.3 I think. And special thanks for re-raising this topic, which I initiated and then forgot to properly follow up :)
> turn the RFC into a general RFC regarding “Process and Policy” – > basically, to decide on clear rules regarding maintainership of > extensions and moving of orphaned extensions to PECL. Individual > extensions could than be handled without the need for much > discussion and be resolved with a simple RFC/voting (or maybe even > without).
Yes, I think having some rules on maintainership would be nice, right now I haven't even considered extensions which have maintainers listed but no longer active, etc. - though I suspect those exist too. But we should start with ones we think are orphans now. I'll update the RFC and put it for vote soon, I think, and then see how we can continue.
-- Stas Malyshev smalyshev@gmail.com

Sara Golemon

8 years ago
On Tue, Jun 12, 2018 at 4:09 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> I'm not sure it's too late for 7.3. If we see that the extension is > unmaintained, we could move it out for 7.3 I think. >
Well, you and cmb are the RMs for 7.3, so you get the largest say in that, but IMO we won't finish sorting out the RFC and get through vote in time for feature freeze and pulling out whole extensions feels like a pretty hefty change to make at that point. Yes, the extensions still exist in PECL, so I wouldn't vote down based on the timeline, but it does make me nervous.
> Sounds like a good idea. If you'd like, please feel free to edit > the RFC to add a section about public notice procedure before > moving. Otherwise, we could just make the procedure separately, > it doesn't *have* to be part of the RFC. >
As it stands now, the RFC needs a fair amount of refactoring to make it about general ownership/abandonment process long term. I can shoehorn this public notice bit in, but it's going to feel weird until a larger rewrite is done. Are you planning to do that? Should cmb since he resurrected the RFC? Open season for whomever cares? -Sara

Christoph Becker

8 years ago
On 13.06.2018 at 16:48, Sara Golemon wrote:
> On Tue, Jun 12, 2018 at 4:09 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote: > >> I'm not sure it's too late for 7.3. If we see that the extension is >> unmaintained, we could move it out for 7.3 I think. > > Well, you and cmb are the RMs for 7.3, so you get the largest say in > that, but IMO we won't finish sorting out the RFC and get through vote > in time for feature freeze and pulling out whole extensions feels like > a pretty hefty change to make at that point. Yes, the extensions > still exist in PECL, so I wouldn't vote down based on the timeline, > but it does make me nervous.
The “Release Process” RFC states[1]: | But they [the roles of the RMs] are not: | * Decide which features, extension or SAPI get in a release or not That said, in my opinion it is too late for 7.3 to move a bundled extension to PECL, except perhaps for unresolved or even unresolvable security reasons. ext/wddx comes to mind, and maybe there are others. [1] <https://wiki.php.net/rfc/releaseprocess#rms_role>
-- Christoph M. Becker

Stas Malyshev

8 years ago
Hi!
> That said, in my opinion it is too late for 7.3 to move a bundled > extension to PECL, except perhaps for unresolved or even unresolvable > security reasons. ext/wddx comes to mind, and maybe there are others.
I'd be happy to move wddx if nobody steps up to maintain it. It has tons of security issues lately (not even sure all are fixed) and it hard to make heads or tails in it without really deep dive, for which I don't think I have time, and nobody else seems to. And since it's a kinda obscure format which in 99% of cases can be replaced by json I suspect...
-- Stas Malyshev smalyshev@gmail.com

Christoph Becker

8 years ago
On 14.06.2018 at 00:47, Stanislav Malyshev wrote:
>> That said, in my opinion it is too late for 7.3 to move a bundled >> extension to PECL, except perhaps for unresolved or even unresolvable >> security reasons. ext/wddx comes to mind, and maybe there are others. > > I'd be happy to move wddx if nobody steps up to maintain it. It has tons > of security issues lately (not even sure all are fixed) and it hard to > make heads or tails in it without really deep dive, for which I don't > think I have time, and nobody else seems to. And since it's a kinda > obscure format which in 99% of cases can be replaced by json I suspect...
*Deprecation* of ext/wddx is part of the “Deprecations for PHP 7.3” RFC[1] draft. Are you planning to pursue this RFC, Nikita? Anyhow, I think moving ext/wddx to PECL for PHP 7.3 might be preferable to a deprecation phase, given that we had discussed this almost a year before[2], and already had an RFC which would only have deprecated the object deserialization[3] withdrawn, but had not actually made any progress. [1] <https://wiki.php.net/rfc/deprecations_php_7_3> [2] <https://externals.io/message/100183> [3] <https://wiki.php.net/rfc/wddx-deprecate-class-instance-deserialization>
-- Christoph M. Becker

Nikita Popov

8 years ago
On Thu, Jun 14, 2018 at 4:00 PM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> On 14.06.2018 at 00:47, Stanislav Malyshev wrote: > > >> That said, in my opinion it is too late for 7.3 to move a bundled > >> extension to PECL, except perhaps for unresolved or even unresolvable > >> security reasons. ext/wddx comes to mind, and maybe there are others. > > > > I'd be happy to move wddx if nobody steps up to maintain it. It has tons > > of security issues lately (not even sure all are fixed) and it hard to > > make heads or tails in it without really deep dive, for which I don't > > think I have time, and nobody else seems to. And since it's a kinda > > obscure format which in 99% of cases can be replaced by json I suspect... > > *Deprecation* of ext/wddx is part of the “Deprecations for PHP 7.3” > RFC[1] draft. Are you planning to pursue this RFC, Nikita? >
Thanks for the reminder, I do plan to pick this up. I'll try to submit this RFC as soon as possible.
> Anyhow, I think moving ext/wddx to PECL for PHP 7.3 might be preferable > to a deprecation phase, given that we had discussed this almost a year > before[2], and already had an RFC which would only have deprecated the > object deserialization[3] withdrawn, but had not actually made any > progress. >
I think our general procedure is to always deprecate prior to moving to PECL, to ensure that the PECL use also throws deprecation warnings (it is an unmaintained extension at that point after all). I'd personally be fine with deprecate+move in 7.3 though, for all the reasons we discussed last time. Nikita

Christoph Becker

8 years ago
On 12.06.2018 at 22:09, Stanislav Malyshev wrote:
> Yes, I think having some rules on maintainership would be nice, right > now I haven't even considered extensions which have maintainers listed > but no longer active, etc. - though I suspect those exist too. […]
From looking at current EXTENSIONS[1], it seems to be rather the other way round, unfortunately. [1] <https://github.com/php/php-src/blob/c904d380a288ed50b62ef93c733883dc2fad2301/EXTENSIONS>
-- Christoph M. Becker

Johannes Schlueter

8 years ago
Hi, On Di, 2018-06-12 at 13:54 +0200, Christoph M. Becker wrote:
> > https://wiki.php.net/rfc/umaintained_extensions > > I think it is *very* important to finally tackle this topic.  Since > it
It's a good subject to think about, but we should be careful not to end with a process and then following it without thought and we have to look at those things individually. For instance with readline this contains two things. For one the `readline()` and related userspace functions, which I assume are not used thaaaat often, but also the interactive shell mode (`php -a` with CLI+readline enabled) and I think the later is quie important to many users and should see similar common responsibility as those key SAPIs, main/ and so on. (I once moved that functionality from SAPI/cli to ext/readline to satisfy distributors who didn't want to statically link readline for license and related reasons) johannes

Yasuo Ohgaki

8 years ago
On Tue, Jun 19, 2018 at 9:37 PM, Johannes Schlüter <johannes@schlueters.de> wrote:
> Hi, > > On Di, 2018-06-12 at 13:54 +0200, Christoph M. Becker wrote: > > > > https://wiki.php.net/rfc/umaintained_extensions > > > > I think it is *very* important to finally tackle this topic. Since > > it > > > It's a good subject to think about, but we should be careful not to end > with a process and then following it without thought and we have to > look at those things individually. > > For instance with readline this contains two things. For one the > `readline()` and related userspace functions, which I assume are not > used thaaaat often, but also the interactive shell mode (`php -a` with > CLI+readline enabled) and I think the later is quie important to many > users and should see similar common responsibility as those key SAPIs, > main/ and so on. (I once moved that functionality from SAPI/cli to > ext/readline to satisfy distributors who didn't want to statically link > readline for license and related reasons) > > johannes
CLI without readline isn't good. --with-libedit is there to replace readline lib. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net