Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] orphan extensions cleanup

Posted by Stanislav Malyshev 
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
Hi

2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <[email protected]>:
> Please comment and discuss!

What about adding the following:
ext/dba
ext/interbase
ext/recode

I tried to look for anything recode, but it seems far gone, although I
did not do an extensive search for it. I'm unsure about the usage
though, but I doubt it can be much, considering we got iconv.

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?

Interbase have already been discussed a fair bit in this thread, and
it does not seem Leister is going to contribute despite being the only
one around interested in this one, at least here on [email protected]

--
regards,

Kalle Sommer Nielsen
kalle@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Daniel Morris
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
Interbase would be much better existing in PECL, since there is no
interest in supporting it by internals. Couchbase and Cassandra both
exist in PECL and both of those are likely more widely used by the
community than Interbase, and both are also still maintained (with
commits as recently as this month.)

--
Daniel Morris
daniel@honestempire.com

On Thu, 18 Aug 2016, at 12:32 AM, Kalle Sommer Nielsen wrote:
> Hi
>
> 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <[email protected]>:
> > Please comment and discuss!
>
> What about adding the following:
> ext/dba
> ext/interbase
> ext/recode
>
> I tried to look for anything recode, but it seems far gone, although I
> did not do an extensive search for it. I'm unsure about the usage
> though, but I doubt it can be much, considering we got iconv.
>
> 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?
>
> Interbase have already been discussed a fair bit in this thread, and
> it does not seem Leister is going to contribute despite being the only
> one around interested in this one, at least here on [email protected]
>
> --
> regards,
>
> Kalle Sommer Nielsen
> kalle@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christopher Jones
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 15/08/2016 6:17 PM, Kalle Sommer Nielsen wrote:
> Hi Stas
>
> 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <[email protected]>:
>> Hi!
>>
>> I'd like to propose an RFC to deal with extensions that currently have
>> no maintainer:
>>
>> https://wiki.php.net/rfc/umaintained_extensions
>

> pdo_oci
> I have heard that maybe Oracle was going to take over this one, but it
> seems fairly inactive, maybe this thread can help reach out to them.

Yep.

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

Thank you!

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 18/08/16 01:02, Daniel Morris wrote:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Daniel Morris
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On Thu, 18 Aug 2016, at 06:58 AM, Lester Caine wrote:
> Can you justify that statement!

A quick comparison on Google Trends will show this, since the beginning
of 2013 Couchbase has been more popular, GitHub also has more PHP
projects for Couchbase than Interbase.

On Thu, 18 Aug 2016, at 06:58 AM, Lester Caine wrote:
> I'd add that PHP5.2/3 is more widely used that PHP7 ...

Interbase will continue to exist 5.{2,3,4,5,6}, and as you're not really
keen to upgrade (30% of your clients are still on 5.2, despite it
reaching end of life over five years ago, and 5.3 reached end of life 2
years ago), removing it from PHP7 shouldn't cause you too much concern,
since (based on your current pace of upgrading) you won't be switching
to PHP7 until 2024.

--
Daniel Morris
daniel@honestempire.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 18/08/16 08:08, Daniel Morris wrote:
> On Thu, 18 Aug 2016, at 06:58 AM, Lester Caine wrote:
>> Can you justify that statement!
>
> A quick comparison on Google Trends will show this, since the beginning
> of 2013 Couchbase has been more popular, GitHub also has more PHP
> projects for Couchbase than Interbase.

Well Github figures are a problem where Hg is more popular amongst
Firebird users and financial services secure systems tend not to publish
their use of code at all. Firebird is used as a free alternative to
Oracle in many large services and at one time Interbase ran much of the
US emergency services - until Borland decided to end of life it in 1999.
For some reason they did not know just how important Interbase was to
many people :(

> On Thu, 18 Aug 2016, at 06:58 AM, Lester Caine wrote:
>> I'd add that PHP5.2/3 is more widely used that PHP7 ...
>
> Interbase will continue to exist 5.{2,3,4,5,6}, and as you're not really
> keen to upgrade (30% of your clients are still on 5.2, despite it
> reaching end of life over five years ago, and 5.3 reached end of life 2
> years ago), removing it from PHP7 shouldn't cause you too much concern,
> since (based on your current pace of upgrading) you won't be switching
> to PHP7 until 2024.

http://php7.lsces.org.uk/ and Firebird is running fine!

The problem with bringing PHP5.2/3 users forward is that nobody can be
bothered to help them. I simply don't have enough time to move the
clients I HAVE got over and I've now stopped taking any more of that
business on simply because there are not enough hours in the day. NOW it
looks like I have to find time to keep the C side of things working as
well ... something that is a lot easier for someone who knows WHY they
are changing the way something works inside PHP as happened with PHP7.
Firebird did not change so the client library is still the same!

Even moving the sites that I HAVE already pulled up to PHP5.6 over to
PHP7 requires additional work and testing so I resent your suggestion
that I'm taking too long doing all this work. Perhaps it is time to give
up even trying to help PHP!

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
2016-08-18 9:46 GMT+02:00 Lester Caine <[email protected]>:
> Well Github figures are a problem where Hg is more popular amongst
> Firebird users and financial services secure systems tend not to publish
> their use of code at all. Firebird is used as a free alternative to
> Oracle in many large services and at one time Interbase ran much of the
> US emergency services - until Borland decided to end of life it in 1999.
> For some reason they did not know just how important Interbase was to
> many people :(
>
> <snip>
>
> The problem with bringing PHP5.2/3 users forward is that nobody can be
> bothered to help them. I simply don't have enough time to move the
> clients I HAVE got over and I've now stopped taking any more of that
> business on simply because there are not enough hours in the day. NOW it
> looks like I have to find time to keep the C side of things working as
> well ... something that is a lot easier for someone who knows WHY they
> are changing the way something works inside PHP as happened with PHP7.
> Firebird did not change so the client library is still the same!
>
> Even moving the sites that I HAVE already pulled up to PHP5.6 over to
> PHP7 requires additional work and testing so I resent your suggestion
> that I'm taking too long doing all this work. Perhaps it is time to give
> up even trying to help PHP!

Honestly Lester, I do enjoy a good morning read but I'm getting a
little tired of this; this have no relevance to the extensions
maintainers. I already understood in your first mail (and all other
mails sent to [email protected]) that interbase/firebird is important to you,
I get that. But the problem at hand is rather different, this is how
we, we as in the Core Developers of PHP, handle extensions that we
give the proper support and maintenance as Rowan pointed out, our
current promise is pretty much a lie since we cannot give extensions
in the core, the support they may need.

It is not like (as also pointed out), that the code will go away and
vanish, it will still be in PECL, and with a PECL release DLLs will
still be compiled for download if you like me, use Windows.

But I kinda expect this to be the end of the off-topic, I'm so tired
that we always end up on a diverted path and would much rather want to
see some more interest in our core extensions.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 18.08.2016 at 01:32, Kalle Sommer Nielsen wrote:

> 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <[email protected]>:
>> 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. 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.

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

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
Hi

2016-08-18 15:03 GMT+02:00 Christoph M. Becker <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
Hi Kalle!

On 18.08.2016 at 15:12, Kalle Sommer Nielsen wrote:

> 2016-08-18 15:03 GMT+02:00 Christoph M. Becker <[email protected]>:
>
>> 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).
>
> 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.

You probably mean win32/build/libs_version.txt (I wasn't aware of this
file; thanks!). AFAICS, none of the external dba drivers are already
there, and the DB 3-5 binaries can't probably be added due to legal issues.

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

That would be great! A quick fix (simply removing the db3 check) made
it compile, but the test suite stalled on dba_flatfile.phpt.
Apparantly, there are issues regarding mode 'n' on Windows/NTFS.

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

Indeed. I've noted that only, because it shows that the extension is
not actively maintained (otherwise the maintainer would almost certainly
have noticed the deprecation warning and fixed it right away).

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 18.08.2016 at 15:46, Christoph M. Becker wrote:

> That would be great! A quick fix (simply removing the db3 check) made
> it compile, but the test suite stalled on dba_flatfile.phpt.

That was actually caused by the test case being broken. I've fixed it
just now: http://git.php.net/?p=php-src.git;a=commit;h=bc1214f2. The
test is (still) failing, though.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On 18.08.2016 at 15:46, Christoph M. Becker wrote:

> On 18.08.2016 at 15:12, Kalle Sommer Nielsen wrote:
>
>> 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.
>
> That would be great!

I have just committed the minimal changes to be able to build dba on
Windows without libdb, see
http://git.php.net/?p=php-src.git;a=commit;h=ad76e8a5.

--
Christoph M. Becker


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Pierre Joye
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:50AM
On Aug 18, 2016 8:03 PM, "Christoph M. Becker" <[email protected]> wrote:
>
> On 18.08.2016 at 01:32, Kalle Sommer Nielsen wrote:
>
> > 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <[email protected]>:
> >> 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.
Anatol Belski
RE: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:51AM
Hi Pierre,

> -----Original Message-----
> From: Pierre Joye [mailto:[email protected]]
> Sent: Friday, August 19, 2016 1:00 PM
> To: Christoph Becker <[email protected]>
> Cc: PHP internals <[email protected]>; Kalle Sommer Nielsen
> <[email protected]>; Stanislav Malyshev <[email protected]>
> Subject: Re: [PHP-DEV] [RFC] orphan extensions cleanup
>
> On Aug 18, 2016 8:03 PM, "Christoph M. Becker" <[email protected]>
> wrote:
> >
> > On 18.08.2016 at 01:32, Kalle Sommer Nielsen wrote:
> >
> > > 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev <[email protected]>:
> > >> 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.

I was checking for possible libs after Christoph's enablement commit last week. At least qdbm looks like possible to be supported. The bundled libcdb is quite old. There are no new releases, but some patches might be available, need to check. Some Tokyo Cabinet ports did exist, but again need research. Closer to the end of the year, time could be taken to do the research and tests, so maybe to support more of dba in 7.2.

Regards

Anatol


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:51AM
On 22.08.2016 at 18:52, Anatol Belski wrote:

> Hi Pierre,
>
>> -----Original Message-----
>> From: Pierre Joye [mailto:[email protected]]
>> Sent: Friday, August 19, 2016 1:00 PM
>> To: Christoph Becker <[email protected]>
>> Cc: PHP internals <[email protected]>; Kalle Sommer Nielsen
>> <[email protected]>; Stanislav Malyshev <[email protected]>
>> Subject: Re: [PHP-DEV] [RFC] orphan extensions cleanup
>>
>> On Aug 18, 2016 8:03 PM, "Christoph M. Becker" <[email protected]>
>>
>>> 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.
>>
>> 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.
>
> I was checking for possible libs after Christoph's enablement commit
> last week. At least qdbm looks like possible to be supported. The
> bundled libcdb is quite old. There are no new releases, but some
> patches might be available, need to check. Some Tokyo Cabinet ports
> did exist, but again need research. Closer to the end of the year,
> time could be taken to do the research and tests, so maybe to support
> more of dba in 7.2.

That would be great!

gdbm shouldn't also be a problem, if we can build that ourselves. But
perhaps most important would be Oracle DB. As config.w32 is now, only
libdb31s and libdb61 are supported.

Anyhow, it might be best not to hijack this thread further, but instead
move the discussion to internals-win. :-)

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Johannes Schlüter
Re: [PHP-DEV] [RFC] orphan extensions cleanup
December 13, 2016 05:51AM
On Mon, 2016-08-15 at 10:17 +0200, Kalle Sommer Nielsen 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



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Joe Watkins
Re: [PHP-DEV] [RFC] orphan extensions cleanup
January 19, 2017 06:50AM
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 <[email protected]>
wrote:

> On Mon, 2016-08-15 at 10:17 +0200, Kalle Sommer Nielsen 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
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Christoph M. Becker
[PHP-DEV] Re: [RFC] orphan extensions cleanup
June 12, 2018 02:00PM
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
Sara Golemon
Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
June 12, 2018 04:20PM
On Tue, Jun 12, 2018 at 7:54 AM, Christoph M. Becker <[email protected]> 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
Christoph M. Becker
Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
June 12, 2018 05:10PM
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
Stanislav Malyshev
[PHP-DEV] Re: [RFC] orphan extensions cleanup
June 12, 2018 10:20PM
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
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
June 12, 2018 10:20PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
June 12, 2018 11:20PM
On 12 June 2018 at 16:01, Christoph M. Becker <[email protected]
<mailto:[email protected]>> 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
Stanislav Malyshev
Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
June 12, 2018 11:40PM
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
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
June 13, 2018 05:00PM
On Tue, Jun 12, 2018 at 4:09 PM, Stanislav Malyshev <[email protected]> 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
Christoph M. Becker
Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
June 13, 2018 10:50PM
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
Christoph M. Becker
Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
June 13, 2018 11:00PM
On 13.06.2018 at 16:48, Sara Golemon wrote:

> On Tue, Jun 12, 2018 at 4:09 PM, Stanislav Malyshev <[email protected]> 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] <https://wiki.php.net/rfc/releaseprocess#rms_role>;

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
[PHP-DEV] Re: [RFC] orphan extensions cleanup
June 13, 2018 11:30PM
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]
https://github.com/php/php-src/blob/c904d380a288ed50b62ef93c733883dc2fad2301/EXTENSIONS

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup
June 14, 2018 12:50AM
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
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login