This is an old revision of the document!
PHP RFC: Cleaning up unmaintained extensions
- Version: 1.0
- Date: 2016-08-07
- Author: Stas Malyshev, stas@php.net
- Status: Draft
- 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.1 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, 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.
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 however looks like inferior solution to me, I'd rather prefer have specific people to claim responsibility.
To be clear, the ideal result of this process is that all extensions find a maintainer. So we want to have the process biased towards finding one. 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
| 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 |
| gettext | 6 | 2007-12-11 | 2015-09-24 | 2015-08-31 |
| pdo_dblib | 19 | 2007-04-17 | 2016-07-15 | 2016-04-01 |
| pdo_oci | 16 | 2005-08-22 | 2015-06-24 | 2015-08-20 |
| 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 | ??? Not sure there's a bug category for it? | |||
| sysvsem | 19 | 2002-04-29 | 2016-04-04 | 2014-09-10 |
| sysvshm | ??? Not sure there's a bug category for it? | |||
| tokenizer | no category for it, but we can also treat it as part of the parser | |||
| xmlrpc (claimed by Cameron Ball) | 11 | 2006-08-11 | 2016-07-17 | 2016-07-22 |
| 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.
Proposed PHP Version(s)
The process is proposed for 7.1.
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.
Proposed Voting Choices
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