Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102235
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 74.125.82.43 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <eedcc507-53ce-257e-d2d5-1365c5228b42@gmx.de>
References: <f790ef52-0a92-a8a3-bb3d-891713b390be@gmail.com> <eedcc507-53ce-257e-d2d5-1365c5228b42@gmx.de>
Date: Tue, 12 Jun 2018 10:15:39 -0400
Message-ID: <CAESVnVpA4ikfE_-U9d637ittCFsUomOFTituyRkcTAnzyMVKbg@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
From: pollita@php.net (Sara Golemon)

On Tue, Jun 12, 2018 at 7:54 AM, Christoph M. Becker <cmbecker69@gmx.de> wr=
ote:
> 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 =E2=80=9CProcess and Policy=E2=
=80=9D =E2=80=93
> 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