PHP (ext/interbase) driver maintenance

Hi

Discussions regarding PHP should be in the public and on the PHP
internals mailing lists, not in private so I'm forwarding this email
to its proper place.

Den tir. 16. apr. 2019 kl. 02.40 skrev Jason Wharton [email protected]:

I would like to introduce myself as the newly elected President of the
Firebird Foundation. One of the major motivations I had in running for this
office was to do all I could to increase the usability of Firebird for as
many languages and platforms as possible. I seek to have you reconsider
demoting our driver from the core to the PECL.

As the original RFC author of this RFC, I will give reply with my
thoughts here inline, and while I'm a Core Developer of PHP, I cannot
speak for every single developer of the team as they are entitled to
their own opinion, so I will make it as abstract as I can; Based on
reading this email (along with the many others I have gotten after I
initially proposed the RFC), it strikes me first that the Firebird
community does not seem to understand a few things, while they have
been iterated over and over again on the mailing lists in the last
month or so, I will try my best to do so again.

Reading your email at first gives me the impression that you may not
have read the RFC or understand it from the technical perspective as
it was presented. The ext/interbase extension was designed almost 20
years ago, it has barely changed since then and was originally
targeting InterBase before Firebird was created. As a bonus the
extension was able to connect to Firebird as the protocol is mostly
the same, requiring very few changes to make the extension work with a
Firebird backend, which itself is great. However, the problem
mentioned in the RFC[1], and further explained in there[2] is that we
had no one to step up and maintain the extension. It was even blindly
ported to PHP7 which in terms spawned the notorious bug #72175[3], we
called out for maintainers multiple times[4][5][6] (and further
mentions of it being broken here[7][8]), I could probably dig out more
but already this list should be a red flag indicator. We had some
maintainers step up in the past to try work out the issues of this
extension, but they have either never touched it or went missing after
a while (also mentioned in the RFC[9]).

What baffles me in this whole debate is the lack of communication from
Firebird's side. I could not find any article posted or a relevant
mailing list or similar where it shows the Firebird Foundation's
commitment into investing time into Drivers, I could however find the
article posted on your website in january[10], claiming that you have
found a maintainer for the extension, which is great, however it lacks
one major detail. No one from Firebird has been in contact with PHP in
regards to this (I cannot stress how important this one is!), there
has been no patches, bug reports or even the slightest communication.
Even the new "maintainer" was not subscribed to PHP internals. The
extension and its code is essentially owned by PHP and for a third
party organization to claim maintainership of something we distribute
in PHP without any communication sounds more like a fork to me, which
is very poor execution from Firebirds side of things.

It was first when the proposal to move the extension out of php-src
came into the light that this was even relayed to PHP internals. I
explained to Martin (the new claimed maintainer) that I wanted to see
concrete patches before the time period of when the voting was
supposed to begin to even remotely consider holding it off and that
similar to this, I do not appreciate conversations in private, they
belong to the public, more than ever especially now. I did not see
any, or even hear any further plans for what the idea with this whole
thing was and still to this moment of writing this response, I am in
the unclear of the direction of this "development" and to prevent my
fellow team members and contributors of PHP the burden of acting like
we actively maintain something which we don't, push it forward and
into PECL.

Moving an extension to PECL does not mean its gone for good. It means
that the extension is not maintained by the PHP Development Team in a
sense that we do not provide fixes in any capacity as apart of the
standard release cycle. PHP has a rather strict release cycle where we
generally do not add new functionality in a release branch (currently
PHP-7.1, PHP-7.2, PHP-7.3), we have policies for keeping backwards
compatibility and such. I'm mentioning this because an extension in
PECL does not have these rules and extensions there are free to change
exactly as they feel like. If the voting passes then naturally the
Firebird foundation are free to claim it on PECL and essentially do
anything you wish with it, it just will not be included in the php-src
distribution anymore (which has less and less meaning nowadays with
package managers). PECL even have Windows integration and can compile
extensions in many flavors.

While I am sure existing users will do what they must to continue having
access to PHP drivers for Firebird, I would very much like to avoid imposing
upon them this inconvenience. I also very much wish to avoid the negative
stigma of being demoted.

I think it is just as important to not further distribute broken and
unmaintained software. The PHP community deserves high quality
extensions and tools for rapid development, this extension does not
live up to those goals and criteria and it has not since before 7.0
was released. That is a bad on the PHP Development Teams end, we tried
to remedy the extension for as long as we could, but now we are at a
point where its a burden to continue that, added with the low bug
reports and feedback we have gotten, it is the best solution for us
(again not speaking directly for everyone). Both ways you look at
this, there is negative stigma involved as it currently stands.

This sends the wrong impression, especially since we have already been
making renewed efforts within the Firebird development umbrella to address
your grievances with the lack of appropriate maintenance of the
(ext/interbase) driver.

My thoughts regarding sending wrong impressions have been expressed
above. However I do honestly appreciate the effort about putting work
into making PHP and Firebird communicate better, however it seems that
the Firebird users who have voiced their opinion regarding this matter
seems to almost deny PDO_Firebird is an actual thing in php-src, I
reckon there was comments regarding it not supporting the same feature
set as that of ext/interbase, perhaps a first task to look at if thats
of interest.

The Firebird Foundation has even secured corporate funding specific to this
driver that remains available to ensure continued development. This type of
funding allocation is the primary purpose of the Firebird Foundation so that
Firebird will have a core team of dedicated developers. I would very much
like to see this funding go to its intended purpose.

I'm not really sure what to respond to this, honestly. It is
unfortunate as it currently stands, however I have expressed above my
personal feelings as a Core Developer of PHP in regards to the actions
done (and the lack of). The communication should be the top priority
when there is money involved, but there seems to be the lack here like
I expressed.

I am personally committed to see that an appropriate level of driver upkeep
is accomplished in order to maintain the continued presense of the iBase
driver in the core of PHP.

Please se my comment about PDO_Firebird above.

Will you please let me know what assurances you require of us in order to
accomplish this?

As the RFC author I'm not keen on disrupting the democratic process
for this, even more so with how events have turned out lately. Firstly
wanting to stop the RFC but no response or patches or even
involvements prior to voting to even get me and the other team members
and contributors some sort of assurance that its not just empty words
and now halfway into the vote again, with what initially strikes me as
someone who are not fully into the topic (I apologies if this is not
the case, but that is the impression I got when reading the email) and
the overall lack of involvement of Firebird in the PHP Development
related areas (internals, mailing lists, bug reports etc) and
therefore I see no reason as currently is, to halt the voting (like
I expressed to Martin, Volker and Lester who has been voices of the
Firebird community).

Thanks and kind regards,
Jason Wharton
Firebird Foundation President

I would like to hear Firebirds standpoint on the issues at hand and
why they come so late, I do not have an answer to this or even an
imaginary one that I could think of to explain any of this.

[1] https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase
[2] https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase#further_rationale
[3] http://bugs.php.net/72175
[4] https://externals.io/message/3673#3680
[5] https://externals.io/message/80838#80920
[6] https://externals.io/message/95172#95191
[7] https://externals.io/message/31388#31448
[8] https://externals.io/message/29469#29618
[9] https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase#introduction
[10] https://firebirdsql.org/en/news/revival-of-php-driver-development/

(I have included parts the original message that spawned this for
internals readers for context.)

-----Original Message-----
From: Helen Borrie [mailto:[email protected]]
Sent: Thursday, April 11, 2019 1:40 PM
To: Jason Wharton
Subject: Fwd: Re: PHP Driver / Maintainer

This is a forwarded message
From: Volker Rehn [email protected]
To: Helen Borrie [email protected]
Date: Thursday, April 11, 2019, 11:38:31 PM
Subject: PHP Driver / Maintainer

===8<==============Original message text=============== Hello Helen,

hope everything is running smoothly in the Southern hemisphere ;-)

I would like to give you an update on <subject>. The voting to exclude the
driver from the main php distribution has started (only people on the
php.internals mailing list can vote, http://news.php.net/php.internals) and
as expected it is not looking good:

https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

Today Martin has finally succeeded to get into the internal php-mailing
list, after he had contacted some guys of the core php team directly. Let's
see ...

best, Volker

--
regards,

Kalle Sommer Nielsen
[email protected]

Hi

Discussions regarding PHP should be in the public and on the PHP
internals mailing lists, not in private so I'm forwarding this email
to its proper place.

Den tir. 16. apr. 2019 kl. 02.40 skrev Jason Wharton [email protected]:

I would like to introduce myself as the newly elected President of the
Firebird Foundation. One of the major motivations I had in running for
this
office was to do all I could to increase the usability of Firebird for as
many languages and platforms as possible. I seek to have you reconsider
demoting our driver from the core to the PECL.

Not once has the fact that an extension exists in PECL instead of core
prevented me from utilizing that extension. The only thing that has ever
prevented me from using an extension is when it is not maintained. I've
been following this entire thread, and I have yet to see what the big deal
about having the extension moved to PECL is. If anything, being in PECL
gives you MORE flexibility as you aren't tied to the PHP release cycle.

As the original RFC author of this RFC, I will give reply with my
thoughts here inline, and while I'm a Core Developer of PHP, I cannot
speak for every single developer of the team as they are entitled to
their own opinion, so I will make it as abstract as I can; Based on
reading this email (along with the many others I have gotten after I
initially proposed the RFC), it strikes me first that the Firebird
community does not seem to understand a few things, while they have
been iterated over and over again on the mailing lists in the last
month or so, I will try my best to do so again.

Reading your email at first gives me the impression that you may not
have read the RFC or understand it from the technical perspective as
it was presented. The ext/interbase extension was designed almost 20
years ago, it has barely changed since then and was originally
targeting InterBase before Firebird was created. As a bonus the
extension was able to connect to Firebird as the protocol is mostly
the same, requiring very few changes to make the extension work with a
Firebird backend, which itself is great. However, the problem
mentioned in the RFC[1], and further explained in there[2] is that we
had no one to step up and maintain the extension. It was even blindly
ported to PHP7 which in terms spawned the notorious bug #72175[3], we
called out for maintainers multiple times[4][5][6] (and further
mentions of it being broken here[7][8]), I could probably dig out more
but already this list should be a red flag indicator. We had some
maintainers step up in the past to try work out the issues of this
extension, but they have either never touched it or went missing after
a while (also mentioned in the RFC[9]).

What baffles me in this whole debate is the lack of communication from
Firebird's side. I could not find any article posted or a relevant
mailing list or similar where it shows the Firebird Foundation's
commitment into investing time into Drivers, I could however find the
article posted on your website in january[10], claiming that you have
found a maintainer for the extension, which is great, however it lacks
one major detail. No one from Firebird has been in contact with PHP in
regards to this (I cannot stress how important this one is!), there
has been no patches, bug reports or even the slightest communication.
Even the new "maintainer" was not subscribed to PHP internals. The
extension and its code is essentially owned by PHP and for a third
party organization to claim maintainership of something we distribute
in PHP without any communication sounds more like a fork to me, which
is very poor execution from Firebirds side of things.

It was first when the proposal to move the extension out of php-src
came into the light that this was even relayed to PHP internals. I
explained to Martin (the new claimed maintainer) that I wanted to see
concrete patches before the time period of when the voting was
supposed to begin to even remotely consider holding it off and that
similar to this, I do not appreciate conversations in private, they
belong to the public, more than ever especially now. I did not see
any, or even hear any further plans for what the idea with this whole
thing was and still to this moment of writing this response, I am in
the unclear of the direction of this "development" and to prevent my
fellow team members and contributors of PHP the burden of acting like
we actively maintain something which we don't, push it forward and
into PECL.

Moving an extension to PECL does not mean its gone for good. It means
that the extension is not maintained by the PHP Development Team in a
sense that we do not provide fixes in any capacity as apart of the
standard release cycle. PHP has a rather strict release cycle where we
generally do not add new functionality in a release branch (currently
PHP-7.1, PHP-7.2, PHP-7.3), we have policies for keeping backwards
compatibility and such. I'm mentioning this because an extension in
PECL does not have these rules and extensions there are free to change
exactly as they feel like. If the voting passes then naturally the
Firebird foundation are free to claim it on PECL and essentially do
anything you wish with it, it just will not be included in the php-src
distribution anymore (which has less and less meaning nowadays with
package managers). PECL even have Windows integration and can compile
extensions in many flavors.

While I am sure existing users will do what they must to continue having
access to PHP drivers for Firebird, I would very much like to avoid
imposing
upon them this inconvenience. I also very much wish to avoid the
negative
stigma of being demoted.

I think it is just as important to not further distribute broken and
unmaintained software. The PHP community deserves high quality
extensions and tools for rapid development, this extension does not
live up to those goals and criteria and it has not since before 7.0
was released. That is a bad on the PHP Development Teams end, we tried
to remedy the extension for as long as we could, but now we are at a
point where its a burden to continue that, added with the low bug
reports and feedback we have gotten, it is the best solution for us
(again not speaking directly for everyone). Both ways you look at
this, there is negative stigma involved as it currently stands.

This sends the wrong impression, especially since we have already been
making renewed efforts within the Firebird development umbrella to
address
your grievances with the lack of appropriate maintenance of the
(ext/interbase) driver.

My thoughts regarding sending wrong impressions have been expressed
above. However I do honestly appreciate the effort about putting work
into making PHP and Firebird communicate better, however it seems that
the Firebird users who have voiced their opinion regarding this matter
seems to almost deny PDO_Firebird is an actual thing in php-src, I
reckon there was comments regarding it not supporting the same feature
set as that of ext/interbase, perhaps a first task to look at if thats
of interest.

The Firebird Foundation has even secured corporate funding specific to
this
driver that remains available to ensure continued development. This
type of
funding allocation is the primary purpose of the Firebird Foundation so
that
Firebird will have a core team of dedicated developers. I would very
much
like to see this funding go to its intended purpose.

I'm not really sure what to respond to this, honestly. It is
unfortunate as it currently stands, however I have expressed above my
personal feelings as a Core Developer of PHP in regards to the actions
done (and the lack of). The communication should be the top priority
when there is money involved, but there seems to be the lack here like
I expressed.

I am personally committed to see that an appropriate level of driver
upkeep
is accomplished in order to maintain the continued presense of the iBase
driver in the core of PHP.

Please se my comment about PDO_Firebird above.

Will you please let me know what assurances you require of us in order to
accomplish this?

As the RFC author I'm not keen on disrupting the democratic process
for this, even more so with how events have turned out lately. Firstly
wanting to stop the RFC but no response or patches or even
involvements prior to voting to even get me and the other team members
and contributors some sort of assurance that its not just empty words
and now halfway into the vote again, with what initially strikes me as
someone who are not fully into the topic (I apologies if this is not
the case, but that is the impression I got when reading the email) and
the overall lack of involvement of Firebird in the PHP Development
related areas (internals, mailing lists, bug reports etc) and
therefore I see no reason as currently is, to halt the voting (like
I expressed to Martin, Volker and Lester who has been voices of the
Firebird community).

Thanks and kind regards,
Jason Wharton
Firebird Foundation President

I would like to hear Firebirds standpoint on the issues at hand and
why they come so late, I do not have an answer to this or even an
imaginary one that I could think of to explain any of this.

[1] https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase
[2]
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase#further_rationale
[3] http://bugs.php.net/72175
[4] https://externals.io/message/3673#3680
[5] https://externals.io/message/80838#80920
[6] https://externals.io/message/95172#95191
[7] https://externals.io/message/31388#31448
[8] https://externals.io/message/29469#29618
[9]
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase#introduction
[10] https://firebirdsql.org/en/news/revival-of-php-driver-development/

(I have included parts the original message that spawned this for
internals readers for context.)

-----Original Message-----
From: Helen Borrie [mailto:[email protected]]
Sent: Thursday, April 11, 2019 1:40 PM
To: Jason Wharton
Subject: Fwd: Re: PHP Driver / Maintainer

This is a forwarded message
From: Volker Rehn [email protected]
To: Helen Borrie [email protected]
Date: Thursday, April 11, 2019, 11:38:31 PM
Subject: PHP Driver / Maintainer

===8<==============Original message text=============== Hello Helen,

hope everything is running smoothly in the Southern hemisphere ;-)

I would like to give you an update on <subject>. The voting to exclude
the
driver from the main php distribution has started (only people on the
php.internals mailing list can vote, http://news.php.net/php.internals)
and
as expected it is not looking good:

https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

Today Martin has finally succeeded to get into the internal php-mailing
list, after he had contacted some guys of the core php team directly.
Let's
see ...

best, Volker

--
regards,

Kalle Sommer Nielsen
[email protected]

--

--
Chase Peeler
[email protected]

Not once has the fact that an extension exists in PECL instead of core
prevented me from utilizing that extension. The only thing that has ever
prevented me from using an extension is when it is not maintained. I've
been following this entire thread, and I have yet to see what the big deal
about having the extension moved to PECL is. If anything, being in PECL
gives you MORE flexibility as you aren't tied to the PHP release cycle.

The 'advantage' up to now of being in core has been that the BULK of the
code changes have been required to track changes in the PHP side of the
interface. The core SQL interface has not basically changed so up until
now it has worked fine for both Firebird and Interbase. So as long as
someone who understands the PHP side of the equation puts the same
generic changes into the driver as in other core extensions then things
carry on working ... but developments in the PHP side have become a lot
more difficult to track than when I did manage to apply fixes to the
driver code many years ago.

Moving forward there has been some substantial changes on both the
Firebird and Interbase side which today could benefit from a separation
but that is not 'essential' to continue to use the the legacy interfaces
as the vast majority of development work on the Firebird side is in
additional SQL functionality and the core way of passing that has not
changed in 25 years so there has been no reason to 'continually update'
the driver, only the wrappers around the basic driver. Which do not
impact the driver extension itself?

--
Lester Caine - G8HFL

Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

Den tir. 16. apr. 2019 kl. 20.09 skrev Lester Caine [email protected]:

The 'advantage' up to now of being in core has been that the BULK of the
code changes have been required to track changes in the PHP side of the
interface. The core SQL interface has not basically changed so up until
now it has worked fine for both Firebird and Interbase. So as long as
someone who understands the PHP side of the equation puts the same
generic changes into the driver as in other core extensions then things
carry on working ... but developments in the PHP side have become a lot
more difficult to track than when I did manage to apply fixes to the
driver code many years ago.

Everytime the topic of interbase comes up, you always referer to
applying fixes, yet I'm yet to see any contributions from you to
actually maintain the code at php-src, am I to understand that this
means you patch your own builds of PHP? Because it is not something
that strengths the argument that has any merit of strengthen the
argument of keeping it, quite the contrary if anything.

Moving forward there has been some substantial changes on both the
Firebird and Interbase side which today could benefit from a separation
but that is not 'essential' to continue to use the the legacy interfaces
as the vast majority of development work on the Firebird side is in
additional SQL functionality and the core way of passing that has not
changed in 25 years so there has been no reason to 'continually update'
the driver, only the wrappers around the basic driver. Which do not
impact the driver extension itself?

--
regards,

Kalle Sommer Nielsen
[email protected]

Everytime the topic of interbase comes up, you always referer to
applying fixes, yet I'm yet to see any contributions from you to
actually maintain the code at php-src, am I to understand that this
means you patch your own builds of PHP? Because it is not something
that strengths the argument that has any merit of strengthen the
argument of keeping it, quite the contrary if anything.

I've never been granted access to commit my own work! But a number of
overhauls of the PHP side I've contributed to and tested the work of
others ... I started with fixing the problems back in 5.2.x and you will
find my contributions on this mail list back then! I was asking about
splitting the fbird_* commands back then but was told there was no need
as there were no differences that warranted it :( Nothing much has
changed in the intervening 11 years ... it's still running the same
sites perfectly ...

--
Lester Caine - G8HFL

Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

--
Lester Caine - G8HFL

Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk