PHP RFC: Cleaning up unmaintained extensions


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.


For the extensions that have no maintainers, the proposal is to:

  1. Issue a call for maintainership on internals list (and maybe other venues, as seen appropriate).
  2. If a maintainer candidate(s) show up:
  3. If they are already committers, assign them as maintainers. The extension is considered maintained from now on, no further action needed.
  4. 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).
  5. If within 3 weeks nobody steps up as a maintainer for extension, it is considered orphaned.
  6. 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

These are core extensions for which there is no official maintainer registered.

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
(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!)


Discussion on internals: http://externals.io/thread/126

rfc/umaintained_extensions.txt · Last modified: 2018/03/01 23:16 by carusogabriel