Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Yasuo Ohgaki]

On Tue, Jun 19, 2018 at 9:37 PM, Johannes Schlüter 
wrote:

> Hi,
>
> On Di, 2018-06-12 at 13:54 +0200, Christoph M. Becker wrote:
>
> > > https://wiki.php.net/rfc/umaintained_extensions
> >
> > I think it is *very* important to finally tackle this topic.  Since
> > it
>
>
> It's a good subject to think about, but we should be careful not to end
> with a process and then following it without thought and we have to
> look at those things individually.
>
> For instance with readline this contains two things. For one the
> `readline()` and related userspace functions, which I assume are not
> used tht often, but also the interactive shell mode (`php -a` with
> CLI+readline enabled) and I think the later is quie important to many
> users and should see similar common responsibility as those key SAPIs,
> main/ and so on. (I once moved that functionality from SAPI/cli to
> ext/readline to satisfy distributors who didn't want to statically link
> readline for license and related reasons)
>
> johannes


CLI without readline isn't good.
--with-libedit is there to replace readline lib.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Johannes Schlüter]

Hi,

On Di, 2018-06-12 at 13:54 +0200, Christoph M. Becker wrote:

> > https://wiki.php.net/rfc/umaintained_extensions
> 
> I think it is *very* important to finally tackle this topic.  Since
> it


It's a good subject to think about, but we should be careful not to end
with a process and then following it without thought and we have to
look at those things individually.

For instance with readline this contains two things. For one the
`readline()` and related userspace functions, which I assume are not
used tht often, but also the interactive shell mode (`php -a` with
CLI+readline enabled) and I think the later is quie important to many
users and should see similar common responsibility as those key SAPIs,
main/ and so on. (I once moved that functionality from SAPI/cli to
ext/readline to satisfy distributors who didn't want to statically link
readline for license and related reasons)

johannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Nikita Popov]

On Thu, Jun 14, 2018 at 4:00 PM, Christoph M. Becker 
wrote:

> On 14.06.2018 at 00:47, Stanislav Malyshev wrote:
>
> >> That said, in my opinion it is too late for 7.3 to move a bundled
> >> extension to PECL, except perhaps for unresolved or even unresolvable
> >> security reasons.  ext/wddx comes to mind, and maybe there are others.
> >
> > I'd be happy to move wddx if nobody steps up to maintain it. It has tons
> > of security issues lately (not even sure all are fixed) and it hard to
> > make heads or tails in it without really deep dive, for which I don't
> > think I have time, and nobody else seems to. And since it's a kinda
> > obscure format which in 99% of cases can be replaced by json I suspect...
>
> *Deprecation* of ext/wddx is part of the “Deprecations for PHP 7.3”
> RFC[1] draft.  Are you planning to pursue this RFC, Nikita?
>

Thanks for the reminder, I do plan to pick this up. I'll try to submit this
RFC as soon as possible.


> Anyhow, I think moving ext/wddx to PECL for PHP 7.3 might be preferable
> to a deprecation phase, given that we had discussed this almost a year
> before[2], and already had an RFC which would only have deprecated the
> object deserialization[3] withdrawn, but had not actually made any
> progress.
>

I think our general procedure is to always deprecate prior to moving to
PECL, to ensure that the PECL use also throws deprecation warnings (it is
an unmaintained extension at that point after all).

I'd personally be fine with deprecate+move in 7.3 though, for all the
reasons we discussed last time.

Nikita

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Christoph M. Becker]

On 14.06.2018 at 00:47, Stanislav Malyshev wrote:

>> That said, in my opinion it is too late for 7.3 to move a bundled
>> extension to PECL, except perhaps for unresolved or even unresolvable
>> security reasons.  ext/wddx comes to mind, and maybe there are others.
> 
> I'd be happy to move wddx if nobody steps up to maintain it. It has tons
> of security issues lately (not even sure all are fixed) and it hard to
> make heads or tails in it without really deep dive, for which I don't
> think I have time, and nobody else seems to. And since it's a kinda
> obscure format which in 99% of cases can be replaced by json I suspect...

*Deprecation* of ext/wddx is part of the “Deprecations for PHP 7.3”
RFC[1] draft.  Are you planning to pursue this RFC, Nikita?

Anyhow, I think moving ext/wddx to PECL for PHP 7.3 might be preferable
to a deprecation phase, given that we had discussed this almost a year
before[2], and already had an RFC which would only have deprecated the
object deserialization[3] withdrawn, but had not actually made any progress.

[1] 
[2] 
[3] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Stanislav Malyshev]

Hi!

> That said, in my opinion it is too late for 7.3 to move a bundled
> extension to PECL, except perhaps for unresolved or even unresolvable
> security reasons.  ext/wddx comes to mind, and maybe there are others.

I'd be happy to move wddx if nobody steps up to maintain it. It has tons
of security issues lately (not even sure all are fixed) and it hard to
make heads or tails in it without really deep dive, for which I don't
think I have time, and nobody else seems to. And since it's a kinda
obscure format which in 99% of cases can be replaced by json I suspect...

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Christoph M. Becker]

On 13.06.2018 at 16:48, Sara Golemon wrote:

> On Tue, Jun 12, 2018 at 4:09 PM, Stanislav Malyshev  
> wrote:
>
>> I'm not sure it's too late for 7.3. If we see that the extension is
>> unmaintained, we could move it out for 7.3 I think.
>
> Well, you and cmb are the RMs for 7.3, so you get the largest say in
> that, but IMO we won't finish sorting out the RFC and get through vote
> in time for feature freeze and pulling out whole extensions feels like
> a pretty hefty change to make at that point.  Yes, the extensions
> still exist in PECL, so I wouldn't vote down based on the timeline,
> but it does make me nervous.

The “Release Process” RFC states[1]:

| But they [the roles of the RMs] are not:
| * Decide which features, extension or SAPI get in a release or not

That said, in my opinion it is too late for 7.3 to move a bundled
extension to PECL, except perhaps for unresolved or even unresolvable
security reasons.  ext/wddx comes to mind, and maybe there are others.

[1] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Christoph M. Becker]

On 12.06.2018 at 23:33, Stanislav Malyshev 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.
> 
> I agree here. If somebody cares enough to update the number, and by that
> commit to maintainership, this is already more than halfway towards the
> solution. We can never force anyone to be an active maintainer, or to
> allocate specific amount of time to fixing bugs or develop features, but
> the problem now is that we don't even have anybody in any maintainership
> capacity. We've had some people listed that haven't been active for
> years, and just remain there by default. I think once we solve this
> problem and have explicit commitment from maintainers, the question of
> how to make this commitment turn into a real work will be much better
> problem to have. We will still have to deal with it, obviously, but I
> think we first have to even get there.

Okay, you've convinced me. :)

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Sara Golemon]

On Tue, Jun 12, 2018 at 4:09 PM, Stanislav Malyshev  wrote:
> I'm not sure it's too late for 7.3. If we see that the extension is
> unmaintained, we could move it out for 7.3 I think.
>
Well, you and cmb are the RMs for 7.3, so you get the largest say in
that, but IMO we won't finish sorting out the RFC and get through vote
in time for feature freeze and pulling out whole extensions feels like
a pretty hefty change to make at that point.  Yes, the extensions
still exist in PECL, so I wouldn't vote down based on the timeline,
but it does make me nervous.

> Sounds like a good idea. If you'd like, please feel free to edit
> the RFC to add a section about public notice procedure before
> moving. Otherwise, we could just make the procedure separately,
> it doesn't *have* to be part of the RFC.
>
As it stands now, the RFC needs a fair amount of refactoring to make
it about general ownership/abandonment process long term.  I can
shoehorn this public notice bit in, but it's going to feel weird until
a larger rewrite is done.  Are you planning to do that? Should cmb
since he resurrected the RFC? Open season for whomever cares?

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Stanislav Malyshev]

Hi!

>    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.

I agree here. If somebody cares enough to update the number, and by that
commit to maintainership, this is already more than halfway towards the
solution. We can never force anyone to be an active maintainer, or to
allocate specific amount of time to fixing bugs or develop features, but
the problem now is that we don't even have anybody in any maintainership
capacity. We've had some people listed that haven't been active for
years, and just remain there by default. I think once we solve this
problem and have explicit commitment from maintainers, the question of
how to make this commitment turn into a real work will be much better
problem to have. We will still have to deal with it, obviously, but I
think we first have to even get there.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Rowan Collins]

On 12 June 2018 at 16:01, Christoph M. Becker > 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

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Stanislav Malyshev]

Hi!

> 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:

Makes sense. Note that abandoned in itself does not mean it will be
moved out - but it is certainly a base for a call for maintainership and
the discussion of

We could also initialize this list with the date of the latest commit or
bug response from the official current maintainer.

> 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"

Sounds like a good idea. If you'd like, please feel free to edit the RFC
to add a section about public notice procedure before moving. Otherwise,
we could just make the procedure separately, it doesn't *have* to be
part of the RFC.

> 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).

Sure, if we just replace a thing with a better thing, there's no point
to look for a maintainer for the inferior thing.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Christoph M. Becker]

On 12.06.2018 at 16:15, Sara Golemon wrote:

> 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'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.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

[Sara Golemon]

On Tue, Jun 12, 2018 at 7:54 AM, Christoph M. Becker  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