Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95204
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.18 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>,
 PHP Internals <internals@lists.php.net>
References: <f790ef52-0a92-a8a3-bb3d-891713b390be@gmail.com>
 <351c6035-2428-5296-2429-69145f7da841@gmx.de>
 <db0ff6bd-8f49-1fc8-5f99-d9253e8dd02e@gmail.com>
Message-ID: <b073742e-e6a5-b8ad-66ce-f2ef66216c95@gmx.de>
Date: Mon, 15 Aug 2016 19:54:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <db0ff6bd-8f49-1fc8-5f99-d9253e8dd02e@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC] orphan extensions cleanup
From: cmbecker69@gmx.de ("Christoph M. Becker")

Hi!

On 15.08.2016 at 18:46, Stanislav Malyshev wrote:

>> Generally, I'm all for moving unmaintained extensions to PECL.
>> However, I wonder on what information the concrete selection of
>> unmaintained extensions in the RFC is based.  If it is
>> php-src/EXTENSIONS, the RFC is moot, in my opinion, as this file is
>> grossly out-dated.  It seems that
> 
> I don't see how it makes it moot, unless that means we actually have
> maintainers for all the extensions but we don't know it. In which case,
> I think RFC is successful, even if leads to just updating EXTENSIONS.
> And since we don't really have anything else, at least for now, we would
> go with the best info we have.

That was badly worded from me.  Actually, I didn't mean to say the RFC
generally is moot, but rather that the selection of extensions is moot
(in my opinion), because it is based on wrong assumptions.

> As you can see, there's also a need for updating EXTENSIONS and figuring
> out if the listed maintainers are indeed still active, which will be
> topic of the followup RFC.

Maybe it would be better to first check the current status quo of
maintainership, and after that taking care of the insufficiently
maintained extensions.

It should be easy to verify whether the maintainers are still interested
in maintaining the respective extension(s); just write them an email and
ask.  If somebody doesn't answer in due time, we also have an answer.

>> The bug tracker statistics appear to present a somewhat more
>> realistic view: <https://bugs.php.net/stats.php>.  The topmost
>> bundled extensions having the most unresolved issues are standard,
>> soap, date, spl and pdo. The XML related extensions (libxml, dom,
>> simplexml, xml, etc.) also sum up.
> 
> The problem is not a sheer number of issues, but the question of if
> there's anybody to take care of them, especially the important ones.
> E.g. I've had to deal with wddx and exif issues, even though I don't
> know both formats well enough - because otherwise we'd have security
> bugs sitting there for a long time. Also we have security issues in
> mysql that nobody is taking care of, and in FTP, and in libxml, and in
> FPM, and in other places.

Okay, the situation wrt. private bug reports is rather special, as
you've already pointed out in the other mail "rethinking security issues
in bugs db".  Unless the extension maintainer has access to these
tickets, (s)he can't be of much help.

-- 
Christoph M. Becker