On 12 June 2018 at 16:01, Christoph M. Becker <cmbecke...@gmx.de
<mailto:cmbecke...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
