rfc:umaintained_extensions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:umaintained_extensions [2017/09/22 13:28] – external edit 127.0.0.1rfc:umaintained_extensions [2018/08/22 11:23] (current) – Fix table indentation carusogabriel
Line 1: Line 1:
 ====== PHP RFC:  Cleaning up unmaintained extensions ====== ====== PHP RFC:  Cleaning up unmaintained extensions ======
-  * Version: 1.0+  * Version: 1.1
   * Date: 2016-08-07   * Date: 2016-08-07
   * Author: Stas Malyshev, stas@php.net   * Author: Stas Malyshev, stas@php.net
-  * Status: Draft +  * Status: Accepted
   * First Published at: http://wiki.php.net/rfc/umaintained_extensions   * First Published at: http://wiki.php.net/rfc/umaintained_extensions
  
 ===== Introduction ===== ===== Introduction =====
 We have a number of extensions that have no assigned maintainer. The proposal is either to find a maintainer for them 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.release.+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 ===== ===== Proposal =====
  
 For the extensions that have no maintainers, the proposal is to: 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).+  - 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 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.    - 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).   - 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.   - 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. +  - 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 however looks like inferior solution to meI'd rather prefer have specific people to claim responsibility+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// 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. +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 ==== ==== Candidate extensions ====
-These are core extensions for which there is no official maintainer registered. +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 ^  ^ Extension      ^ Bugs in DB (minus reqs)      ^  Oldest open bug          ^ Newest bug ^ Most recent bugfix ^ 
Line 33: Line 34:
 | pdo_odbc | 26 | 2007-06-22 | 2016-01-18 | 2009-12-11 | | pdo_odbc | 26 | 2007-06-22 | 2016-01-18 | 2009-12-11 |
 | readline | 4 | 2012-03-31 | 2001-01-26 | 2015-12-11 | | readline | 4 | 2012-03-31 | 2001-01-26 | 2015-12-11 |
-| pspell | 2 |  2014-03-19  | 2016-04-19 | 2008-09-16 | +| pspell | 2 | 2014-03-19  | 2016-04-19 | 2008-09-16 | 
 | sysvmsg | No bug category | | sysvmsg | No bug category |
 | sysvsem | 19 | 2002-04-29 | 2016-04-04 | 2014-09-10 | | sysvsem | 19 | 2002-04-29 | 2016-04-04 | 2014-09-10 |
 | sysvshm  | No bug category |  | sysvshm  | No bug category | 
-| 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 |  | wddx | 6 | 2006-03-17 | 2016-08-11 | 2016-08-11 | 
  
Line 43: Line 43:
  
 Default build of PHP would not have the extensions that will be moved out. They still could be built from PECL sources. 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) ===== ===== Proposed PHP Version(s) =====
  
-The process is proposed for 7.1+The process is proposed for 7.3 and all future PHP versions
  
 ===== Future Scope ===== ===== Future Scope =====
  
 We may need to refresh the list of current maintainers (since some maintainers have moved on) and repeat the process We may need to refresh the list of current maintainers (since some maintainers have moved on) and repeat the process
-in the future.+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 ===== ===== 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. 
 +
 +<doodle title="Institute the policy of cleaning up unmaintained extensions as described in this RFC" auth="stas" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
 +
 +Voting starts on 2018-06-17, and ends on 2018-06-26 23:59 PDT.
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
Line 60: Line 76:
  
 ===== References ===== ===== References =====
-Discussion on internals: http://externals.io/thread/126+Discussion on internals: http://externals.io/thread/126 https://externals.io/message/95172
  
  
rfc/umaintained_extensions.1506086901.txt.gz · Last modified: 2017/09/22 13:28 by 127.0.0.1