Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] [VOTE] Cleaning up unmaintained extensions »

[RFC] [VOTE] Cleaning up unmaintained extensions

php.internals

Stas Malyshev

8 years ago
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

Christopher Jones

8 years ago
On 18/6/18 5:43 am, Stanislav Malyshev 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). > > 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
-- http://twitter.com/ghrd

Peter Cowburn

8 years ago
On 17 June 2018 at 20:43, 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_ejkxtensions > <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). >
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.

Christoph Becker

8 years ago
On 18.06.2018 at 14:23, Peter Cowburn wrote:
> On 17 June 2018 at 20:43, Stanislav Malyshev <smalyshev@gmail.com> wrote: > >> 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_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). > > 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

Sara Golemon

8 years ago
On Sun, Jun 17, 2018 at 3:43 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> 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.

Yasuo Ohgaki

8 years ago
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

Stas Malyshev

8 years ago
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

Tim Starling

8 years ago
On 20/06/18 05:46, Stanislav Malyshev 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. -- Tim Starling

Stas Malyshev

8 years ago
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

Andrey Andreev

8 years ago
Hi, On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> 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.

Christoph Becker

8 years ago
On 29.06.2018 at 16:54, Andrey Andreev wrote:
> On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote: >> >>> 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

Andrey Andreev

8 years ago
Hi again, On Fri, Jun 29, 2018 at 6:07 PM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> On 29.06.2018 at 16:54, Andrey Andreev wrote: > >> On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote: >>> >>>> 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.

Yasuo Ohgaki

8 years ago
On Fri, Jun 29, 2018 at 2:16 PM, Tim Starling <tstarling@wikimedia.org> wrote:
> On 20/06/18 05:46, Stanislav Malyshev 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

Tim Starling

8 years ago
On 30/06/18 11:44, Yasuo Ohgaki 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. -- Tim Starling

Yasuo Ohgaki

8 years ago
On Sat, Jun 30, 2018 at 11:42 AM, Tim Starling <tstarling@wikimedia.org> wrote:
> On 30/06/18 11:44, Yasuo Ohgaki 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

Nikita Popov

8 years ago
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

Lester Caine

8 years ago
On 19/06/18 21:20, Nikita Popov wrote:
> 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

Stas Malyshev

8 years ago
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

Lester Caine

8 years ago
On 19/06/18 21:48, Stanislav Malyshev wrote:
>> 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

Stas Malyshev

8 years ago
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

Lester Caine

8 years ago
On 20/06/18 06:04, Stanislav Malyshev wrote:
> 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

Nikita Popov

8 years ago
On Tue, Jun 19, 2018 at 11:47 PM, Lester Caine <lester@lsces.co.uk> wrote:
> On 19/06/18 21:48, Stanislav Malyshev wrote: > >> 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

Lester Caine

8 years ago
On 20/06/18 10:25, Nikita Popov wrote:
> 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.
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

Stas Malyshev

8 years ago
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

Christoph Becker

8 years ago
On 17.06.2018 at 21:43, Stanislav Malyshev wrote:
> 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

Stas Malyshev

8 years ago
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

Christoph Becker

8 years ago
On 27.06.2018 at 22:50, Stanislav Malyshev wrote:
> 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