Hi!
I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:
https://wiki.php.net/rfc/umaintained_extensions
The vote ends 2018-06-26 23:59 PDT.
I have added some discussion about active maintainers and abandonment
procedures, this can be refined further later. I also kept the list of
the candidates as-is for now, but I will update it soon and probably
make a separate wiki page for maintaining it. Please note this list is
not part of the vote (the vote is on the process, not specific list
which will change all the time).
Thanks,
Stas Malyshev
smalyshev@gmail.com
Hi!
I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:https://wiki.php.net/rfc/umaintained_extensions
The vote ends 2018-06-26 23:59 PDT.
I have added some discussion about active maintainers and abandonment
procedures, this can be refined further later. I also kept the list of
the candidates as-is for now, but I will update it soon and probably
make a separate wiki page for maintaining it. Please note this list is
not part of the vote (the vote is on the process, not specific list
which will change all the time).Thanks,
-
I know we're all online all the time, but I would have gone for a 4 week period instead of 3. Many countries have significant vacation periods.
-
the "community maintained" option looks OK.
-
Since this is a process & policy RFC that has a long lifespan as a reference, what about renaming it to 'PHP RFC: Process for Unmaintained Extensions'?
[Somehow https://wiki.php.net/rfc should capture these active references. Currently they are in the same section as things such as PHP 5.3 EOL]
Chris
Hi!
I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:https://wiki.php.net/rfc/umaintained_ejkxtensions
https://wiki.php.net/rfc/umaintained_extensionsThe vote ends 2018-06-26 23:59 PDT.
I have added some discussion about active maintainers and abandonment
procedures, this can be refined further later. I also kept the list of
the candidates as-is for now, but I will update it soon and probably
make a separate wiki page for maintaining it. Please note this list is
not part of the vote (the vote is on the process, not specific list
which will change all the time).
Can anyone point me at the discussion thread for the revival of this RFC?
On the mailing list there have been a small number of mails broadly about
extensions and maintainers, and it looks like the RFC was only edited a few
days ago, but I feel like a dummy and can't find the "I'd like to revive
this RFC" thread at all.
Thanks,
Stas Malyshev
smalyshev@gmail.com
I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:https://wiki.php.net/rfc/umaintained_ejkxtensions
https://wiki.php.net/rfc/umaintained_extensionsThe vote ends 2018-06-26 23:59 PDT.
I have added some discussion about active maintainers and abandonment
procedures, this can be refined further later. I also kept the list of
the candidates as-is for now, but I will update it soon and probably
make a separate wiki page for maintaining it. Please note this list is
not part of the vote (the vote is on the process, not specific list
which will change all the time).Can anyone point me at the discussion thread for the revival of this RFC?
On the mailing list there have been a small number of mails broadly about
extensions and maintainers, and it looks like the RFC was only edited a few
days ago, but I feel like a dummy and can't find the "I'd like to revive
this RFC" thread at all.
I had not opened a new thread, but rather replied to the original
discussion thread in https://externals.io/message/95172#102234.
--
Christoph M. Becker
I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:https://wiki.php.net/rfc/umaintained_extensions
The vote ends 2018-06-26 23:59 PDT.
I have added some discussion about active maintainers and abandonment
procedures, this can be refined further later. I also kept the list of
the candidates as-is for now, but I will update it soon and probably
make a separate wiki page for maintaining it. Please note this list is
not part of the vote (the vote is on the process, not specific list
which will change all the time).
FTR; My yes vote comes with the endorsement that I'd like to see us
followup on that future scope work to make this into an on-going
policy rather than focus on the specific extensions in this moment.
On Mon, Jun 18, 2018 at 4:43 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:https://wiki.php.net/rfc/umaintained_extensions
The vote ends 2018-06-26 23:59 PDT.
Just to be sure consequence of "readline" removal.
With CLI, "php -a" and "history" works without readline?
Does it work as dynamically loaded module?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Hi! I would like to open the vote for the RFC about cleaning up the unmaintained extensions: https://wiki.php.net/rfc/umaintained_extensions <https://wiki.php.net/rfc/umaintained_extensions> The vote ends 2018-06-26 23:59 PDT.Just to be sure consequence of "readline" removal.
With CLI, "php -a" and "history" works without readline?
Does it work as dynamically loaded module?
CLI can still use readline library. This would be about readline PHP
extension.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
Hi! I would like to open the vote for the RFC about cleaning up the unmaintained extensions: https://wiki.php.net/rfc/umaintained_extensions <https://wiki.php.net/rfc/umaintained_extensions> The vote ends 2018-06-26 23:59 PDT.Just to be sure consequence of "readline" removal.
With CLI, "php -a" and "history" works without readline?
Does it work as dynamically loaded module?CLI can still use readline library. This would be about readline PHP
extension.
Actually, readline support in "php -a" is part of the extension. The
extension hooks the SAPI module. See PHP_MINIT_FUNCTION(cli_readline)
in readline_cli.c.
Readline is the only extension in your list that I would be sad about
losing. I use it every day, I guess a lot of devs do.
-- Tim Starling
Hi!
Readline is the only extension in your list that I would be sad about
losing. I use it every day, I guess a lot of devs do.
It's not "losing", per se, as the code doesn't get erased, it just moved
to PECL. All distros can build it from there just as they do now. Then
again, if it's super-important and doesn't have any major issues, we
could keep it (or any other extension) around in "community maintained"
status for a while.
--
Stas Malyshev
smalyshev@gmail.com
Hi,
Hi!
Readline is the only extension in your list that I would be sad about
losing. I use it every day, I guess a lot of devs do.It's not "losing", per se, as the code doesn't get erased, it just moved
to PECL. All distros can build it from there just as they do now. Then
again, if it's super-important and doesn't have any major issues, we
could keep it (or any other extension) around in "community maintained"
status for a while.
If "php -a" doesn't work without ext/readline (and I know it never
works for me if I don't install the distro-provided php-readline
package), then it is super-important.
Cheers,
Andrey.
Readline is the only extension in your list that I would be sad about
losing. I use it every day, I guess a lot of devs do.It's not "losing", per se, as the code doesn't get erased, it just moved
to PECL. All distros can build it from there just as they do now. Then
again, if it's super-important and doesn't have any major issues, we
could keep it (or any other extension) around in "community maintained"
status for a while.If "php -a" doesn't work without ext/readline (and I know it never
works for me if I don't install the distro-provided php-readline
package), then it is super-important.
It's not about removing readline support for the interactive PHP shell,
see https://externals.io/message/102282#102307.
--
Christoph M. Becker
Hi again,
Readline is the only extension in your list that I would be sad about
losing. I use it every day, I guess a lot of devs do.It's not "losing", per se, as the code doesn't get erased, it just moved
to PECL. All distros can build it from there just as they do now. Then
again, if it's super-important and doesn't have any major issues, we
could keep it (or any other extension) around in "community maintained"
status for a while.If "php -a" doesn't work without ext/readline (and I know it never
works for me if I don't install the distro-provided php-readline
package), then it is super-important.It's not about removing readline support for the interactive PHP shell,
see https://externals.io/message/102282#102307.
I know it's not about that, but the problem is that currently (or on
7.0.x at least) the interactive shell doesn't work without the
extension.
Cheers,
Andrey.
On Fri, Jun 29, 2018 at 2:16 PM, Tim Starling tstarling@wikimedia.org
wrote:
Hi!
Hi! I would like to open the vote for the RFC about cleaning up the unmaintained extensions: https://wiki.php.net/rfc/umaintained_extensions <https://wiki.php.net/rfc/umaintained_extensions> The vote ends 2018-06-26 23:59 PDT.Just to be sure consequence of "readline" removal.
With CLI, "php -a" and "history" works without readline?
Does it work as dynamically loaded module?CLI can still use readline library. This would be about readline PHP
extension.Actually, readline support in "php -a" is part of the extension. The
extension hooks the SAPI module. See PHP_MINIT_FUNCTION(cli_readline)
in readline_cli.c.Readline is the only extension in your list that I would be sad about
losing. I use it every day, I guess a lot of devs do.
readline has license issue. I miss it but I wouldn't object for removing it.
Let's use libedit for CLI by default and always.
Issue may be who is going to do this. If nobody volunteers, I may do this.
--
Yasuo Ohgaki
readline has license issue. I miss it but I wouldn't object for removing it.
Let's use libedit for CLI by default and always.
Issue may be who is going to do this. If nobody volunteers, I may do this.
The discussion is about the readline extension, which includes support
for both libedit and the GNU Readline library. You can't use libedit
without the readline extension.
-- Tim Starling
On Sat, Jun 30, 2018 at 11:42 AM, Tim Starling tstarling@wikimedia.org
wrote:
readline has license issue. I miss it but I wouldn't object for removing
it.
Let's use libedit for CLI by default and always.
Issue may be who is going to do this. If nobody volunteers, I may do
this.The discussion is about the readline extension, which includes support
for both libedit and the GNU Readline library. You can't use libedit
without the readline extension.
./configure --without-readline
makes CLI binary with broken "-a" support as you know.
I'm suggesting libedit capability for CLI binary "without" readline module.
i.e. Statically compiled libedit support in CLI binary.
--
Yasuo Ohgaki
On Sun, Jun 17, 2018 at 9:43 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:https://wiki.php.net/rfc/umaintained_extensions
The vote ends 2018-06-26 23:59 PDT.
I have added some discussion about active maintainers and abandonment
procedures, this can be refined further later. I also kept the list of
the candidates as-is for now, but I will update it soon and probably
make a separate wiki page for maintaining it. Please note this list is
not part of the vote (the vote is on the process, not specific list
which will change all the time).
I really don't like this.
There are two extensions that I'm aware of where we have strong technical
grounds to remove them, that's wddx (for reasons of security and
questionable utility) and interbase (has a major bug since the PHP 7
migration and there is nobody with knowledge of this exotic DB driver to
fix it).
If we have technical grounds for a removal and nobody is willing to step up
to resolve the issues, then I'm all for moving extensions to PECL. If this
is not the case, then I feel that removing them will not make the situation
any better (especially seeing relatively common extensions like gettext,
readline and ftp on that list). Extensions without official maintainer in
php-src tend to be passively maintained, e.g. I remember merging various
PRs to the ftp extension over the last few years (and of course, small
extensions like gettext just don't get many changes over time). Moving an
extension to PECL effectively makes it completely unmaintained.
To me, moving extensions to PECL is a Pretty Big Deal. It's something that
should be done on a case-by-case basis, possibly with an RFC, not something
that happens based on a blanket policy.
Regards.
Nikita
and interbase (has a major bug since the PHP 7
migration and there is nobody with knowledge of this exotic DB driver to
fix it).
What Bug!
It's passing all the test that I run on it perfectly stably otherwise I
would not even bother with PHP7. But the problem supporting ANY driver
is the exotic nature of PHP is just as difficult as the tools it needs
to interface with to make a fully functional stack ...
--
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
Hi!
What Bug!
It's passing all the test that I run on it perfectly stably otherwise I
would not even bother with PHP7. But the problem supporting ANY driver
is the exotic nature of PHP is just as difficult as the tools it needs
to interface with to make a fully functional stack ...
I have four bugs for interbase and four for firebird submitted just
recently, as security issues. Do you want to take care of them? I can
assign them to you if you want to take care of them.
Thanks,
Stas Malyshev
smalyshev@gmail.com
What Bug!
It's passing all the test that I run on it perfectly stably otherwise I
would not even bother with PHP7. But the problem supporting ANY driver
is the exotic nature of PHP is just as difficult as the tools it needs
to interface with to make a fully functional stack ...
I have four bugs for interbase and four for firebird submitted just
recently, as security issues. Do you want to take care of them? I can
assign them to you if you want to take care of them.
The last time I managed to patch php was over 15 years ago, I have not
been able to get a handle on the new structure used by PHP7 in part
because I've not had time to do any C coding since. I'm still working on
moving PHP5.2 code to work on PHP7 while keeping the stack working on
W10 and maintained versions of SUSE Linux. And some of the stuff I
thought I'd finished upgrading is not working again :(
I'm not seeing any bugs listed in bugs.php.net that are security risks.
I don't touch PDO_firebird as it does not handle key Firebird features
so looking at 'InterBase related' only returns 8 bugs, and one of them
is missing documentation on the fbird_ aliases that I use in the ADOdb
Firebird driver. THAT is something I do spend time keeping tidy, and
fixes some of the niggles raw access encounters, but I will have a look
at the 2017 bugs that I'd not been aware of ... the other bugs are
somewhat exotic but not security matters.
--
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
Hi!
The last time I managed to patch php was over 15 years ago, I have not
been able to get a handle on the new structure used by PHP7 in part
because I've not had time to do any C coding since. I'm still working on
moving PHP5.2 code to work on PHP7 while keeping the stack working on
W10 and maintained versions of SUSE Linux. And some of the stuff I
thought I'd finished upgrading is not working again :(
php7 builds are not that different from php5 builds, and I suspect the
issues discovered are also present in earlier versions.
I'm not seeing any bugs listed in bugs.php.net that are security risks.
Security issues are not publicly visible. If you have php account, I
could assign them to you and you could see them. Or I could arrange a
copy for you, if you intend to work on them.
Thanks,
Stas Malyshev
smalyshev@gmail.com
php7 builds are not that different from php5 builds, and I suspect the
issues discovered are also present in earlier versions.
Marius has had more luck understanding the nuances of changes and
massaging my previous attempts in with his fixes, but I don't think
either of us are totally comfortable with the C end of things! Things
have changed somewhat in the 40 years since I got my MSc in 'Digital
Systems' and today even PHP is black magic at times :(
I'm not seeing any bugs listed in bugs.php.net that are security risks.
Security issues are not publicly visible. If you have php account, I
could assign them to you and you could see them. Or I could arrange a
copy for you, if you intend to work on them.
Current builds of Interbase and Firebird are moving further apart and
security is one area affected. It may well be that we need to split out
the Firebird aliases and current builds of Firebird 3 have different
security layers to FB2.x and Interbase now. I would at least like to see
a copy of what we are talking about and see if I have any chance of
being able to work on them ...
You consider Firebird a niche area, and similarly the Firebird
developers consider PHP the same as the main application software is
Delphi and C/C++ so trying to get help from either end has always been a
battle. But for me it is still a much more reliable base than MySQL yet
new users have little option but to live with second grade tools.
I'm not sure just what accounts I have on PHP these days. I used to have
logins but I forget nowadays what for. I would just like to get back to
producing content rather than firefighting changes every day ...
--
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
What Bug!
It's passing all the test that I run on it perfectly stably otherwise I
would not even bother with PHP7. But the problem supporting ANY driver
is the exotic nature of PHP is just as difficult as the tools it needs
to interface with to make a fully functional stack ...I have four bugs for interbase and four for firebird submitted just
recently, as security issues. Do you want to take care of them? I can
assign them to you if you want to take care of them.The last time I managed to patch php was over 15 years ago, I have not
been able to get a handle on the new structure used by PHP7 in part because
I've not had time to do any C coding since. I'm still working on moving
PHP5.2 code to work on PHP7 while keeping the stack working on W10 and
maintained versions of SUSE Linux. And some of the stuff I thought I'd
finished upgrading is not working again :(I'm not seeing any bugs listed in bugs.php.net that are security risks. I
don't touch PDO_firebird as it does not handle key Firebird features so
looking at 'InterBase related' only returns 8 bugs, and one of them is
missing documentation on the fbird_ aliases that I use in the ADOdb
Firebird driver. THAT is something I do spend time keeping tidy, and fixes
some of the niggles raw access encounters, but I will have a look at the
2017 bugs that I'd not been aware of ... the other bugs are somewhat exotic
but not security matters.
Just to clarify which bug I was referring to in that mail, it's this one:
https://bugs.php.net/bug.php?id=72175
There are three issues that must be addressed:
- The issue in the original bug report: Connecting to the same DB multiple
times does not work. - The use of zend_list_delete() in *_close() functions, which is
memory-unsafe. - Incorrect interaction of closing and multiple shared connections. While
the underlying connection is shared, closing one resource should not close
all the other ones, but also not result in any leaks (this ties into the
previous point -- you can't just use zend_list_delete for that!) You may
need to implement a double resource indirection to properly handle this,
one holding the actual connection and another holding the connection
resource.
If you or someone who is familiar with interbase could fix these issues,
that would be highly appreciated.
Thanks,
Nikita
Just to clarify which bug I was referring to in that mail, it's this one:
https://bugs.php.net/bug.php?id=72175There are three issues that must be addressed:
- The issue in the original bug report: Connecting to the same DB multiple
times does not work.- The use of zend_list_delete() in *_close() functions, which is
memory-unsafe.- Incorrect interaction of closing and multiple shared connections. While
the underlying connection is shared, closing one resource should not close
all the other ones, but also not result in any leaks (this ties into the
previous point -- you can't just use zend_list_delete for that!) You may
need to implement a double resource indirection to properly handle this,
one holding the actual connection and another holding the connection
resource.If you or someone who is familiar with interbase could fix these issues,
that would be highly appreciated.
Is there anything in the changes to the code in PHP7 that are ACTUALLY
to do with changes to interbase/firebird? On website systems I only ever
have a 'singleton' database connection so don't hit this problem, but
having just spent half an hour looking through the various notes on
different lists it seems to be the way zend handles resources in PHP7
rather than anything to do with the database? THIS is where the nuances
of PHP7 need to be understood to be able to read your third point ...
where does one need to understand how the database works?
I am assuming that my next step here is to work out how
zend_list_delete() is intended to be used, perhaps compare that with
it's use in other database drivers, and work out just what was broken in
7.0.3 and why ... and "implement a double resource indirection" ...
which is much easier to implement if you understand why it is now necessary?
--
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
Hi!
There are two extensions that I'm aware of where we have strong
technical grounds to remove them, that's wddx (for reasons of security
and questionable utility) and interbase (has a major bug since the PHP 7
migration and there is nobody with knowledge of this exotic DB driver to
fix it).
I mostly agree, but this RFC is not for discussing specific extensions,
it's for establishing the policy of what we do with such extensions, and
how.
like gettext, readline and ftp on that list). Extensions without
official maintainer in php-src tend to be passively maintained, e.g. I
Or not. As is the case with several of them.
years (and of course, small extensions like gettext just don't get many
changes over time). Moving an extension to PECL effectively makes it
completely unmaintained.
I think if it doesn't have official maintainer and nobody touched it for
years, it's completely unmaintained right now. But for cases like this,
the RFC says:
Option: for some extensions, which are clearly needed but nobody stepped
up in person to claim maintainership, we can have designated “community
maintained” status, which would mean PHP developers as a group have
shared responsibility for this extension.
To me, moving extensions to PECL is a Pretty Big Deal. It's something
that should be done on a case-by-case basis, possibly with an RFC, not
something that happens based on a blanket policy.
I do not see any contradiction between this and what RFC says. In fact,
RFC specifically says:
In case there are objections to moving unmaintained extension to PECL,
separate RFC vote can be held about the move, initiated by the RMs of
the current release or any interested party. The decision can be taken
for each extension individually.
So what exactly you don't like here? It's pretty much exactly the
opposite of "blanket policy".
I am sorry if I am missing something, but it looks to me like you're
saying "I don't like this, we should do this instead" and then literally
you are saying exactly what the RFC is saying. Where is the problem?
--
Stas Malyshev
smalyshev@gmail.com
I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:https://wiki.php.net/rfc/umaintained_extensions
The vote ends 2018-06-26 23:59 PDT.
Seems the vote should have been closed already. :)
--
Christoph M. Becker
Hi!
Seems the vote should have been closed already. :)
Indeed! Thank you for the reminder, and sorry about me not putting
reminder on my calendar to send the email about it. So here it goes:
The vote result is 19 for and 4 against, which is 82% approving. This
means this RFC has been accepted.
I have created the page https://wiki.php.net/todo/extensions to track
extensions that currently lack proper maintainership. I will update it
and anybody interested is welcome to take part. I think we'll next have
to issue some calls for maintainership. Suggestions about venues to do
it and the texts to use for it are welcome.
--
Stas Malyshev
smalyshev@gmail.com
I have created the page https://wiki.php.net/todo/extensions to track
extensions that currently lack proper maintainership. I will update it
and anybody interested is welcome to take part.
I've updated the list regarding the most recent bugfix[1] for
ext/enchant. (Note that there are two categories in the bugtracker
regarding Enchant: Spelling functions/Enchant related and PECL/enchant.)
Anyhow, I think that ext/enchant desperately needs a maintainer with
regard to Enchant 2[2].
[1]
http://git.php.net/?p=php-src.git;a=commit;h=5acb8381b22f4acf629d8fc89b4e0872f1a0825c
[2] https://externals.io/message/100882
--
Christoph M. Becker