[RFC] orphan extensions cleanup View as Markdown

2016-08-15 10:23 GMT+02:00 Sebastian Bergmann sebastian@php.net:

I consider this part of the core. It's (mostly) auto-generated anyway, right?

The token list is generated from the core using
ext/tokenizer/tokenizer_data_gen.sh, rest is just to expose the two
functions, so yes pretty much

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Hi!

enchant:
I thought Pierre maintained enchant? Despite it haven't had much real
activity for years

Well there are not much changes in the api.

And it works. So -1 here.

Wait, -1 for what? Having a maintainer? How that makes sense? OK,
there's no changes in API, but tomorrow comes security issue - who's
going to take care of it? Would we just ship knowingly broken code then
and not even tell users?

gettext
WordPress can optionally use gettext for some of their po/mo files,
I'm not entirely sure how this is today[1], but it might be worth
taking into consideration if there are other users.

Here as much as I do not like it. I have to oppose it. That is a major
breakage (no, pecl is not the same).

What is major breakage - having a maintainer for this extension? I'm
sorry, I don't understand it.

Stas Malyshev
smalyshev@gmail.com

Hi Adam

2016-08-15 23:34 GMT+02:00 Adam Baratz adam.baratz@gmail.com:

As one of those two people, it would help to have an official maintainer for
this extension. The path for "something's broken" or "something should be
different" to "committed fix" has been pretty murky.

First of all, great job on the recent pdo_dblib activity, its great to
see someone is actively interested in keeping this alive.

I'm interested in putting my name forward for this. It would help to know
more about what's expected. In particular, when PRs poke at broader design
questions with the extension, what's the maintainer's role? One example:
https://github.com/php/php-src/pull/2017

As for expectations, I think its generally expected that the
maintainer oversees bugs, and future development of the extension. An
example could be that a security issue is present in the extension and
having someone that understands the code able to review, fix and work
on it is good, instead of (like Stas mentioned), having someone look
into the code without fully understanding it, and potentially breaking
something else (kinda like what happened to ext/exif).

As a maintainer, you are pretty much the one that oversees the
extension, making sure its in working condition (to continue being in
the core), having tests passes, bug reports and PRs. Ofcourse other
core developers may from time to time touch the extension to fix
something, and in that case make sure to double check that there is no
obvious regressions (we all do make mistakes!).

From seeing your past commitment to pdo_dblib, I'm a +1 keeping this
extension with you as a maintainer, and I'm sure Anatol (cced) who
seems to also be active in some of the PRs say yes to that too.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Hi!

I've added myself to EXTENSIONS as PDO_OCI maintainer; can you take it
out of the RFC?

Done, and thank you!

--
Stas Malyshev
smalyshev@gmail.com

Hi Stas,

The list has been reduced since first opening the discussion, some
maintainers have come forward for some of those first mentioned.

There are still some outstanding extensions though, and I'd like it if we
could move forward with this RFC: either finding maintainers or moving them
out.

Could you possibly find some time to push forward with this please ?

Cheers
Joe

On Tue, Aug 23, 2016 at 4:44 PM, Johannes Schlüter johannes@schlueters.de
wrote:

readline
If removed, I guess this won't affect sapi/cli?

It would. In 5.3 or so I moved the interactive shell to the readline
extension (php -a) in order to help distributors who like to have
extensions shared.

I think "actual" readline functionality isn't used often in PHP, i.e.
GitHub doesn't seem to have any relevant results except phpt files,
syntax highlight descriptors etc.
https://github.com/search?l=php&p=1&q=readline&type=Code&utf8=%E2%9C%93

If we remove the extension and move the shell part back into sapi/cli we
have to teach distributors to link against readline or libedit and users
won't have a way to "fix" this without recompiling complete PHP.

I'm open for a discussion (probably in a different thread) about this.
If needed I can do readline maintenance.

tokenizer
Like you mentioned, I think this should be kept in the core and
possibly maintained as a part of the parser. I do write some
development tools every now and then and make use of this amazing
extension and will only want it to be kept.

The script to produce this is by me, if needed I can step in as official
maintainer. A nice thing would be if we could get rid of the script and
somehow generate this as part of the parser (which might mean making it
part of the engine) ...

johannes

2016-08-15 18:05 GMT+02:00 Lester Caine lester@lsces.co.uk:

Don't go there again!

If there is no active maintainer, it just creates a burden on us core
developers that have to maintain it to the best of our abilities if
any, but there have not been anyone to take over the charge of this
extension, so unless someone does now, I do not see a reason to keep
this in the core. I understand that there are users of this extension,
but we cannot guarantee it to be in any sort of stable working
condition if there isn't anyone around to work on it.

Alternatively we still have ext/pdo_firebird, which I assume will
continue to work with Interbase systems. If not then I'm sorry, but I
do not want another extension on our checklist if no one is willing to
work on it.

Same issue for ext/mssql, although in MSSQL's case we do have
ext/pdo_dblib (pdo_mssql), ext/odbc & ext/pdo_odbc as an alternative.
If there is someone who can actively work on it, then it can have PECL
releases and if there is a big demand for it, I do not see why it
cannot return to the core at a point in time it is well maintained
(either extension that is)

--
regards,

Kalle Sommer Nielsen
kalle@php.net

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.

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

both of those are likely more widely used by the
community than Interbase,

Can you justify that statement!
I'd add that PHP5.2/3 is more widely used that PHP7 ...

And as already said it's not that we don't want to maintain it, it's
that we have no one who is competent enough to maintain it.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Hi

2016-08-18 15:03 GMT+02:00 Christoph M. Becker cmbecker69@gmx.de:

I don't know, but most certainly not on Windows. I had a look at
ext/dba, because I like that we have it bundled, but got 3 failing tests
(flatfile and inifile), which might be caused by running in a Vagrant
box on NTFS. So I tried to compile on Windows, just to learn that
config.w32 is totally out-dated. It doesn't support individual config
options for the different drivers, but rather checks whether db3 is
found, and only then configures the built in drivers. Of course, db3 is
not part of the delivered deps, what is likely the reason that
dba_php.dll isn't distributed anymore as of PHP 5.3 (it would make
sense, IMO, to ship dba_php.dll with the built-in drivers plus those
whose requirements could be bundled in the deps).

Fixing config.w32 shouldn't be too hard (it may take quite some time to
test with the different drivers, though), but I expect further issues
would have to be solved. Besides some unresolved bugs[1], for instance,
it still uses zend_get_parameters_array_ex() at least once[2], even
though this API has been deprecated as of PHP 7.0.0.

Hmm interesting, I can try take a look once I'm at home again.
Extensions that can support more features in newer versions and such
are usually not checked on Windows, as unlike m4 files we do not
compile check for symbols and such and assume a certain version as
minimum, but with the low targeted audience we have that builds PHP on
their on, this is not an issue. We do have win32/libs.txt I think that
lists the libs we use for distro builds.

But I will have to look at our deps and see if it is possible to get
this running again with some cross reference to the m4.

As for zend_get_parameters_array_ex() usage, this should be a no
brainer quick fix.

[1]
https://bugs.php.net/search.php?cmd=display&package_name[]=DBM%2FDBA+related
[2] https://github.com/php/php-src/blob/PHP-7.0.9/ext/dba/dba.c#L654

--
regards,

Kalle Sommer Nielsen
kalle@php.net

2016-08-15 7:53 GMT+02:00 Stanislav Malyshev smalyshev@gmail.com:

Please comment and discuss!

What about adding the following:
ext/dba

As for DBA, this extension have not really seen any major updates or
anything since 2009 when the Tokyo Cabinet support was added (PHP
5.3), is this still used largely or?

I don't know, but most certainly not on Windows. I had a look at
ext/dba, because I like that we have it bundled, but got 3 failing tests
(flatfile and inifile), which might be caused by running in a Vagrant
box on NTFS. So I tried to compile on Windows, just to learn that
config.w32 is totally out-dated. It doesn't support individual config
options for the different drivers, but rather checks whether db3 is
found, and only then configures the built in drivers. Of course, db3 is
not part of the delivered deps, what is likely the reason that
dba_php.dll isn't distributed anymore as of PHP 5.3 (it would make
sense, IMO, to ship dba_php.dll with the built-in drivers plus those
whose requirements could be bundled in the deps).

Fixing config.w32 shouldn't be too hard (it may take quite some time to
test with the different drivers, though), but I expect further issues
would have to be solved.

The last time I checked it was for the 5.3 windows support big jump.

If I remember correctly many banckends were not available on windowd
(mainly vc6). Some may be available now.

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

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
smalyshev@gmail.com

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

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]
https://github.com/php/php-src/blob/c904d380a288ed50b62ef93c733883dc2fad2301/EXTENSIONS

--
Christoph M. Becker

On Tue, Jun 19, 2018 at 9:37 PM, Johannes Schlüter johannes@schlueters.de
wrote:

Hi,

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 thaaaat 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
yohgaki@ohgaki.net