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

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

[Christoph M. Becker]

On 12.06.2018 at 22:09, Stanislav Malyshev wrote:

> Yes, I think having some rules on maintainership would be nice, right
> now I haven't even considered extensions which have maintainers listed
> but no longer active, etc. - though I suspect those exist too. […]

>From looking at current EXTENSIONS[1], it seems to be rather the other
way round, unfortunately.

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

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

[Stanislav Malyshev]

Hi!

> 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

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.

And special thanks for re-raising this topic, which I initiated and then
forgot to properly follow up :)

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

Yes, I think having some rules on maintainership would be nice, right
now I haven't even considered extensions which have maintainers listed
but no longer active, etc. - though I suspect those exist too. But we
should start with ones we think are orphans now. I'll update the RFC and
put it for vote soon, I think, and then see how we can continue.

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

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

[Christoph M. Becker]

Hi Stas!

On 15.08.2016 at 07:53, Stanislav Malyshev wrote:

> I'd like to propose an RFC to deal with extensions that currently have
> no maintainer:
> 
> https://wiki.php.net/rfc/umaintained_extensions
> 
> The main goal of the RFC is to initiate the process that by the time of
> 7.1 release will result in no extensions in PHP core being unmaintained.
> The process would be as follows:
> 
> 1. Issue a call for maintainers (specific details of how, where, etc.
> are to be discussed, ideas welcome).
> 2. Wait for suitable time and hopefully find new maintainers for most or
> all extensions. For some stable ones not much commitment is needed
> beyond declaring you are willing to be responsible for them, should the
> need arise, for others some bugfixing may be in order :)
> 3. If after suitable time we can not find anybody to care enough for the
> extension to be responsible, move the extension from core to PECL.
> 
> Please note that the ideal result is 2, not 3, but the goal is still to
> have no unmaintained extensions in core.

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

-- 
Christoph M. Becker

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

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

[Christoph M. Becker]

Hi!

On 15.08.2016 at 22:39, Stanislav Malyshev wrote:

>> Maybe it would be better to first check the current status quo of
>> maintainership, and after that taking care of the insufficiently
>> maintained extensions.
> 
> I think we can do both in parallel. I'll try to write the second RFC
> soon (hopefully I'll have time) and we can do the maintainer list
> refersh together with deciding what to do with unmaintaned extensions.

Sounds good to me.  If I can be of assistance, please let me know.

-- 
Christoph M. Becker


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

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

[Stanislav Malyshev]

Hi!

> Maybe it would be better to first check the current status quo of
> maintainership, and after that taking care of the insufficiently
> maintained extensions.

I think we can do both in parallel. I'll try to write the second RFC
soon (hopefully I'll have time) and we can do the maintainer list
refersh together with deciding what to do with unmaintaned extensions.

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

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

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

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

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

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

[Stanislav Malyshev]

Hi!

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

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.

> Again, I don't complain that the maintainers are inactive (what is 
> absolutely fine for me), but rather that php-src/EXTENSIONS is
> totally out-dated.

True, but that only makes the maintainership status update *more*
necessary, not less.

> The bug tracker statistics appear to present a somewhat more
> realistic view: .  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.

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

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

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

[Christoph M. Becker]

On 15.08.2016 at 07:53, Stanislav Malyshev wrote:

> I'd like to propose an RFC to deal with extensions that currently have
> no maintainer:
> 
> https://wiki.php.net/rfc/umaintained_extensions
> 
> The main goal of the RFC is to initiate the process that by the time of
> 7.1 release will result in no extensions in PHP core being unmaintained.
> The process would be as follows:
> 
> 1. Issue a call for maintainers (specific details of how, where, etc.
> are to be discussed, ideas welcome).
> 2. Wait for suitable time and hopefully find new maintainers for most or
> all extensions. For some stable ones not much commitment is needed
> beyond declaring you are willing to be responsible for them, should the
> need arise, for others some bugfixing may be in order :)
> 3. If after suitable time we can not find anybody to care enough for the
> extension to be responsible, move the extension from core to PECL.
> 
> Please note that the ideal result is 2, not 3, but the goal is still to
> have no unmaintained extensions in core.
> 
> Please comment and discuss!

Thanks for your work on this RFC! :-)

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
at least a third of the maintainers listed there have been inactive for
years.  For instance, Stefan is claimed to be the maintainer of ftp, but
his most recent commit to this extension appears to be from 2002.  (No
complaint, just an observation.)  Another example is sqlite3, where
Scott's most recent commit has been 5 years ago.  Yet another example:
Marcus's most recent commit to simplexml is from 2008.  As final example
I mention bcmath, where Andi has made his most recent commit 2004.

Again, I don't complain that the maintainers are inactive (what is
absolutely fine for me), but rather that php-src/EXTENSIONS is totally
out-dated.

The bug tracker statistics appear to present a somewhat more realistic
view: .  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.

-- 
Christoph M. Becker

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