Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] orphan extensions cleanup

Posted by Stanislav Malyshev 
Stanislav Malyshev
[PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
Hi Stas

2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sebastian Bergmann
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
2016-08-15 10:23 GMT+02:00 Sebastian Bergmann <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On Mon, Aug 15, 2016 at 7:53 AM, Stanislav Malyshev <[email protected]>
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
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
2016-08-15 12:41 GMT+02:00 Nikita Popov <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
[PHP-DEV] Re: [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Pierre Joye
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On Aug 15, 2016 3:17 PM, "Kalle Sommer Nielsen" <[email protected]> wrote:
>
> Hi Stas
>
> 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <[email protected]>:
> > 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).

> 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
Stanislav Malyshev
[PHP-DEV] Re: [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
2016-08-15 18:05 GMT+02:00 Lester Caine <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 15/08/16 18:02, Kalle Sommer Nielsen wrote:
> 2016-08-15 18:05 GMT+02:00 Lester Caine <[email protected]>:
>> > 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
2016-08-15 19:09 GMT+02:00 Lester Caine <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
[PHP-DEV] Re: [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
[PHP-DEV] Re: [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Adam Baratz
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
>
> 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
Lester Caine
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 15/08/16 18:48, Kalle Sommer Nielsen wrote:
> 2016-08-15 19:09 GMT+02:00 Lester Caine <[email protected]>:
>> 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/[email protected]/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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
Hi Adam

2016-08-15 23:34 GMT+02:00 Adam Baratz <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
2016-08-16 0:07 GMT+02:00 Lester Caine <[email protected]>:
> https://www.mail-archive.com/[email protected]/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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Pierre Joye
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
Hi Stas,

On Aug 15, 2016 11:50 PM, "Stanislav Malyshev" <[email protected]> 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
> smalyshev@gmail.com
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
2016-08-16 1:27 GMT+02:00 Lester Caine <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 16/08/16 02:11, Kalle Sommer Nielsen wrote:
> 2016-08-16 1:27 GMT+02:00 Lester Caine <[email protected]>:
>> 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?

There have been several 'attempts' to drop ext/interbase, all well
documented on this list. PHP developers may not think Firebird is very
popular, and probably from a PHP base it isn't but it IS used
extensively in large areas of the World. 40 years ago I could tell
clients what line of code to change while on the phone. 15 years ago
when I was looking to augment proprietary code with web based, and PHP
seemed the natural stepping stone so I started using PHP5 in parallel
with C/C++ based systems. These days I'm lucky is I can remember if a
job was in C or PHP let alone what module or function will fix a
problem. BUT I did sit down with a clean copy of the source code and my
hg based DVCS allowed me to produce a set of guide lines from the
postgres driver as to the mods needed to bring the interbase one up to
date. I spent the best part of a week back last December trying to make
progress, but that is when
https://gist.github.com/laruence/f3af903012902818d7da was pointed out as
an alternative approach and I rolled back and started again from that.
Xinchen Hui put some fixes in based on my testing and I believe that was
what was pushed back in January. My hg mirror has finally synced over
night and come up with a couple of clashes on the test files, but I
understand those differences since any GOOD Firebird developer will tell
you that creating a database on the fly is a security risk and Firebird
is essentially designed to work with an existing one rather than
creating dummy ones while testing! My tests always use an existing test
database.

> 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?

We ... the Firebird community ... are trying to provide the support, but
earning money is perhaps a more pressing use of time these days :( And
simply trying to get PHP5.2 systems to run on later PHP's is just
another hold up on any progress to new code!

>> 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.

The only problem at that time was the M$ way of working. Pierre would
not use the firebird client library unless it was rebuilt with the same
tools as the php builds, but the whole point of a client library was to
match different systems. Even today the client library that
ext/interbase uses is compiled for the engine compile rules rather than
the PHP ones. Especially on Windows.

> 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?

TIME ... I still have some 30% of my clients on PHP5.2 - with Firebird
1.5 and yet every system that I've moved to PHP5.6 needs checking on
every update because it's still not uncommon for something to pop up and
cause problems.

TODAY I am working on a total overhaul of the form management system
used with bitweaver in order to keep my best client happy. Hence the
discussion on 'simple variable'. To be honest I don't care what way PHP
goes on handling variables as I think I now have a working setup, but it
WOULD be nice if all that effort was more readily usable by many PHP users.

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 16/08/2016 11:11, Lester Caine wrote:
> There have been several 'attempts' to drop ext/interbase, all well
> documented on this list. PHP developers may not think Firebird is very
> popular, and probably from a PHP base it isn't but it IS used
> extensively in large areas of the World.

Please carefully read Kalle's motivation for dropping it. It has nothing
to do with how popular Firebird is, and everything to do with who is
responsible for fixing any serious bugs that crop up *in the
ext/interbase code*.

Note as well that dropping it doesn't mean taking away your ability to
use it - it will still be on PECL, and many Linux distros won't even
change their package name. It's mostly just labelling who is promising
to maintain it - as long as it's in core, the promise is "it will be
stable in stable versions of PHP, and security maintained in security
maintained versions of PHP".

If there is nobody actively maintaining it, that promise is basically a
lie, so moving it to PECL is just giving it the more honest label of "it
will be maintained as and when someone volunteers the time for a
particular issue".

I'm sure everyone agrees is that the ideal situation is *not* to drop
it, and instead to find someone willing to commit to maintain it. But
there's no point saying it's maintained if nobody is actually performing
that role.

Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 16/08/16 15:55, Rowan Collins wrote:
> I'm sure everyone agrees is that the ideal situation is *not* to drop
> it, and instead to find someone willing to commit to maintain it. But
> there's no point saying it's maintained if nobody is actually performing
> that role.

While my name is not against maintaining it, that is what I have been
doing since I first started using PHP. My problem is that despite having
programmed in C/C++ since long before USING PHP, I find it very
difficult to actually understand the C code that makes it up. I have no
problems with the test side and we have a stable test suite for testing
against outside of PHP but many of the 'changes' in the code base ARE
generic changes to some core process and trying to mirror them into an
unmaintained extension is the problem here. Only people who understand
WHY they are making a change which affects every extension really know
how to do that. Trying to work out the PHP7 changes without a deep
understanding if what was needed was why *I* could not handle it ... and
I'm sure other extension maintainers were in the same boat?

http://php7.lsces.org.uk/ibtest.php tests what we want to do, and
nothing there has changed since I first used it back in 2004 and the
next step is to test with FB3 and PHP7 but I've not had time to set up a
suitable target site as yet. Any firebird user knows the password to get
in ... 'masterke' for those who don't ...

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
Hi Lester,

On 16/08/2016 16:16, Lester Caine wrote:
> I have no
> problems with the test side and we have a stable test suite for testing
> against outside of PHP but many of the 'changes' in the code base ARE
> generic changes to some core process and trying to mirror them into an
> unmaintained extension is the problem here. Only people who understand
> WHY they are making a change which affects every extension really know
> how to do that.

That does make sense: a maintainer needs a combination of knowledge of
the PHP/Zend internals, and the third-party library / API the extension
is targetting. That's a tough combination to find.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
[PHP-DEV] Re: [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login