PHP RFC: Cleaning up unmaintained extensions
- Version: 1.1
- Date: 2016-08-07
- Author: Stas Malyshev, stas@php.net
- Status: Accepted
- First Published at: http://wiki.php.net/rfc/umaintained_extensions
Introduction
We have a number of extensions that have no assigned maintainer. The proposal is either to find a maintainer for them or move them out of core. The RFC proposes the procedure for doing this for 7.3 release and repeat it for each subsequent release.
Proposal
For the extensions that have no maintainers, the proposal is to:
- Issue a call for maintainership on internals list (and maybe other venues, such as thematic PHP communities, as seen appropriate).
- If a maintainer candidate(s) show up:
- If they are already committers, assign them as maintainers. The extension is considered maintained from now on, no further action needed.
- Otherwise, ask them to submit a couple of patches for existing bugs in the extension, of their choice. If these are ok, issue them php.net account with appropriate permissions and assign them as maintainers for the claimed extension. If extensions has no bugs to fix, assign them as maintainers immediately (php.net account may not yet be needed).
- If within 3 weeks nobody steps up as a maintainer for extension, it is considered orphaned.
- All orphaned extensions are converted to PECL modules and removed from core repository. There should be a public announcement procedure before this happens, with the details not defined of this RFC but to be worked out by RMs and the community (either with separate RFC or just by consensus).
- 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.
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. This is to be accepted as an inferior solution, which need to be eventually resolved by either finding a maintainer or finding an alternative for the extension.
To be clear, the ideal result of this process is that all core extensions find a maintainer. So we want to have the process biased towards finding one, not removing extensions from core. However, if we fail to do so, we rather claim it explicitly than ship buggy, unmaintained and possibly insecure code to the users.
Candidate extensions
These are core extensions for which there is no official maintainer registered. Please note that the exact content of this list is not part of the vote - it can change with new maintainers coming up or old maintainers retiring, and there probably would be a separate list maintained as necessary.
| Extension | Bugs in DB (minus reqs) | Oldest open bug | Newest bug | Most recent bugfix |
|---|---|---|---|---|
| enchant | 4 | 2008-02-21 | 2009-10-28 | 2008-02-23 |
| ftp | 26 | 2010-05-10 | 2016-06-06 | 2016-08-16 |
| gettext | 6 | 2007-12-11 | 2015-09-24 | 2015-08-31 |
| pdo_odbc | 26 | 2007-06-22 | 2016-01-18 | 2009-12-11 |
| readline | 4 | 2012-03-31 | 2001-01-26 | 2015-12-11 |
| pspell | 2 | 2014-03-19 | 2016-04-19 | 2008-09-16 |
| sysvmsg | No bug category | |||
| sysvsem | 19 | 2002-04-29 | 2016-04-04 | 2014-09-10 |
| sysvshm | No bug category | |||
| wddx | 6 | 2006-03-17 | 2016-08-11 | 2016-08-11 |
Backward Incompatible Changes
Default build of PHP would not have the extensions that will be moved out. They still could be built from PECL sources. The focus of this RFC, however, is for establishing procedures for unmaintained extensions rather than dealing with specific extensions, so decision about each extension can be taken separately.
Proposed PHP Version(s)
The process is proposed for 7.3 and all future PHP versions.
Future Scope
We may need to refresh the list of current maintainers (since some maintainers have moved on) and repeat the process in the future.
The proposed procedure is to add years to each maintainer's status in the maintainers list, with the year to be updated manually by the maintainer. If by end of January of the year the last updated year is past the last year (e.g., 2018 or less in January 2020), the extension is deemed to be abandoned by the maintainer. In this case, the maintainer would be asked to clarify the maintainership status, and absent response or with a negative response, the extension will be considered having no maintainer. This can be changed at any moment if the existing or new maintainer comes up (again, the priority is always towards finding the maintainer, not moving stuff out).
To initiate this procedure, the years should be initialized with the last commit or last bug response from the maintainer to the maintained extension code or bugs.
Proposed Voting Choices
Vote “Yes” is for acceptance of this RFC as the basis for PHP policy towards unmaintained extensions. Vote “No” is for rejection of this RFC.
Since this RFC does not change the language, technical limit for passing is 50%+1 vote, however if it does not gather 2/3 “Yes” vote, I would like to hear from the opposing voices first and maybe improve it before we can implement it to satisfy their concerns.
Voting starts on 2018-06-17, and ends on 2018-06-26 23:59 PDT.
Patches and Tests
Depend on which extensions will be moved (if none, yay, all extensions are maintained now!)
References
Discussion on internals: http://externals.io/thread/126 https://externals.io/message/95172