Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102239
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.195 as permitted sender)
To: internals@lists.php.net
References: <f790ef52-0a92-a8a3-bb3d-891713b390be@gmail.com>
 <eedcc507-53ce-257e-d2d5-1365c5228b42@gmx.de>
 <CAESVnVpA4ikfE_-U9d637ittCFsUomOFTituyRkcTAnzyMVKbg@mail.gmail.com>
 <a5df69e8-b5ce-f956-fbd5-a6a03bb3a9a0@gmx.de>
Message-ID: <c434f7d3-8012-a2c7-94a5-8af018161ce1@gmail.com>
Date: Tue, 12 Jun 2018 22:11:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <a5df69e8-b5ce-f956-fbd5-a6a03bb3a9a0@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
From: rowan.collins@gmail.com (Rowan Collins)

On 12 June 2018 at 16:01, Christoph M. Becker <cmbecker69@gmx.de 
<mailto:cmbecker69@gmx.de>> wrote:

    I'm afraid this might be misused.  It's too easy to update the year
    number, without actually doing *any* real maintenance work (“I'll come
    back to that later” …).  Some automated process would be nice, but
    manually checking the bug tracker for maintenance work (particularly
    wrt. security issues), and/or the commit log seems to be okay for now.



That sounds like you're looking for a technical solution to an 
organisational / social problem: if someone lists themselves as a 
maintainer, they are making a commitment to volunteer their effort. That 
commitment could be defined somewhere if it's not already, but it's 
never going to be an automatically measurable SLA.

It might be useful to have tools to help monitor - e.g. a dashboard that 
runs a couple of queries to give an idea of recent activity on each 
extension - but there's always going to be a judgement call. What if 
some helpful volunteer raises 100 bugs, and only the 10 most serious of 
them are fixed within a release cycle; is the maintainer failing to keep 
up, or are they correctly triaging and prioritising? What if a security 
issue is raised, but there's no clear fix? No statistic will give you a 
true view of the effort a maintainer has put into trying.

So the important thing there is what is the policy: who gets to decide 
that a maintainer is not fulfilling their commitment, and what is the 
process for officially removing them? If someone else wants to take over 
maintainership, that may be as simple as "would you like me to help?"; 
but if it's a case of marking an extension unmaintained, it could be 
controversial.


The problem Sara's suggestion fixes is different: right now, maintainers 
make a commitment once, for an indeterminate amount of time. By 
periodically making a change, maintainers are simply saying "yes, I am 
still interested in maintaining this extension", in a format that can be 
easily reported on.

I think this is a useful concept, and the timeline could be linked to 
the annual release cycle; for instance:

- if the last promise in the OWNER file is over a year old at time of 
Alpha, check if they are still interested, and seek a new maintainer if not
- if it is still not updated by RC, mark the extension as pending removal
- if it is still unclaimed by the *next* alpha (i.e. a year later), 
remove it from core


Regards,
-- 
Rowan Collins
[IMSoP]