On Tue, Jun 12, 2018 at 7:54 AM, Christoph M. Becker <cmbecke...@gmx.de> wrote: > I think it is *very* important to finally tackle this topic. Since it > is rather late for actually moving several extensions to PECL for PHP > 7.3, and since this would be an ongoing process anyway, I suggest to > turn the RFC into a general RFC regarding “Process and Policy” – > basically, to decide on clear rules regarding maintainership of > extensions and moving of orphaned extensions to PECL. Individual > extensions could than be handled without the need for much discussion > and be resolved with a simple RFC/voting (or maybe even without). > Hear! Hear!
Per issue #1, I'd suggest an OWNERS file per ext/*/ dir with names and year ranges. Continued ownership demarked by explicitly incrementing the end year BY THE MAINTAINER. An extension is considered abandoned if the end year is not updated by the following January. Example: ext/hash/OWNER might contain "pollita 2005-2018" (and other entries). 2019 rolls around, even if it's December and I haven't updated the end year, it's still not considered abandoned until January 2020. This leaves the second half of a year for auditing "soon to be adandoned" exts and reach out to current "owners" and/or find potential replacements for the following year. I'd also suggest that this information is read in by bugs.php.net so that extension owners can make easy dashboards from their relevant bugs, but that's not really related to this RFC topic beyond deciding on a file format (maybe JSON?) I 100% agree that #3 is the least ideal option and should be avoided wherever possible. It requires that literally nobody GAF about the extension AND that we're unable to recruit support from outside users. I think removal of dead extensions which have no immediate replacement should come with a public notice period. Posts on high traffic sites such as Reddit and headers added to relevant chapter(s) of the manual for example. If this gets us some developer at a company who relies on the extension but never considered Open Source as a viable track, then we've won twice. I do say "which have no immediate replacement" because I don't think we'd need a public notice for something like the removal of mysql or mcrypt as they both had strong viable alternatives. Similar if we ever decide to replace ext/gmp with github.com/sgolemon/gmpi extension (shameless plug). -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
