[RFC] [Discussion] Deprecate PEAR and recommend Composer

1 month ago by James Titcumb — view source — reply

unread

Folks,

Presenting the RFC for deprecating PEAR and recommending Composer as the
recommended
PHP package installer:

https://wiki.php.net/rfc/deprecate_pear_recommend_composer

Plan to move to vote on or shortly after 24th October all being well.

Thanks
James

1 month ago by Christoph M. Becker — view source — reply

unread

Presenting the RFC for deprecating PEAR and recommending Composer as the
recommended
PHP package installer:

https://wiki.php.net/rfc/deprecate_pear_recommend_composer

Plan to move to vote on or shortly after 24th October all being well.

Apparently, this RFC has been withdrawn in the meantime. I would like
to know why. :)

Christoph

1 month ago by James Titcumb — view source — reply

unread

Apparently, this RFC has been withdrawn in the meantime. I would like
to know why. :)

I absolutely agree with you - a discussion took place on the PHP Foundation
slack. I raised a concern that it should be discussed here on the list for
transparency. I am frustrated that it was not.

The short version of that discussion is that PEAR is maintained by someone
else; the PEAR group apparently is separate from the PHP group, as I
understand it. The only thing related to PHP/internals is the fact PEAR is
bundled with PHP and that the PEAR website is a subdomain pear.php.net.

I withdrew the RFC because it seems this is a can of worms.

Presenting the RFC for deprecating PEAR and recommending Composer as the
recommended
PHP package installer:

https://wiki.php.net/rfc/deprecate_pear_recommend_composer

Plan to move to vote on or shortly after 24th October all being well.

Apparently, this RFC has been withdrawn in the meantime. I would like
to know why. :)

Christoph

1 month ago by Pierre Joye — view source — reply

unread

Hi James,

Apparently, this RFC has been withdrawn in the meantime. I would like
to know why. :)

I absolutely agree with you - a discussion took place on the PHP
Foundation slack. I raised a concern that it should be discussed here on
the list for transparency. I am frustrated that it was not.

The short version of that discussion is that PEAR is maintained by someone
else; the PEAR group apparently is separate from the PHP group, as I
understand it.

I don't remember the reason back then but it was basically maintained by
core devs at some point, including myself.

I also wanted to propose that long ago but the composer's team disagree as
they wanted to remain fully independent. It may still be the case (you
surely ask them).

also given there is PIE now, this was theast reason to keep pear/pecl
installer around, suggesting to use composer/pie cannot hurt and keep
composer independent.

a removal/fade it way could be a future next step.

1 month ago by Jakub Zelenka — view source — reply

unread

Hi,

Hi James,

On Fri, Oct 10, 2025, 3:29 PM James Titcumb titcumbjames@gmail.com
wrote:

Apparently, this RFC has been withdrawn in the meantime. I would like
to know why. :)

I absolutely agree with you - a discussion took place on the PHP
Foundation slack. I raised a concern that it should be discussed here on
the list for transparency. I am frustrated that it was not.

The short version of that discussion is that PEAR is maintained by
someone else; the PEAR group apparently is separate from the PHP group, as
I understand it.

I don't remember the reason back then but it was basically maintained by
core devs at some point, including myself.

Is that still the case though? I don't think that any current core
developer has access to their GH organizattion. Or do you still have access
/ control to do any changes there and make it deprecated? My main issue
with this RFC is that it's about project that we don't effectively control
and I'm not sure here is anyone who can make any such change to it. From
what I see it's currently maintained by Chuck who, I guess, also control
the project. Or am I wrong?

Alternatively we could potentially propose here move that away from the PHP
domain if we think it's not good for PHP image but that could mean that we
might completely shut it down without any deprecation if there is no
agreement with the current maintainers.

So the ideal case would be to put together some plan how to either get it
deprecated and moved away. But for that we need to first here from the
current maintainers and get them on board.

If here is anyone who has access to PEAR and can comment on this, that
would be great! I also CC'd Chuck as I think it's crucial to get his
opinion on this.

Kind regards,

Jakub

1 month ago by Brent Roose — view source — reply

unread

The only thing related to PHP/internals is the fact PEAR is bundled with
PHP and that the PEAR website is a subdomain pear.php.net.

In my opinion, this is sufficient reason to have an RFC for it. A quick
search through the RFCs showed a handful of website-related ones:

Then there's the fact that Pear comes bundled with PHP, even more of an
argument that internals have at least something to say about it. Several
RFCs have addressed bundling/unbundling third party plugins before. Again,
a quick search:

To me, and I believe to a significant part of the PHP community, what's
most important is for PHP to acknowledge that composer is its de-facto
standard package manager. This doesn't mean composer cannot operate
independently anymore, but an endorsement would make a lot of sense.

Brent

Hi,

Hi James,

On Fri, Oct 10, 2025, 3:29 PM James Titcumb titcumbjames@gmail.com
wrote:

Apparently, this RFC has been withdrawn in the meantime. I would like
to know why. :)

I absolutely agree with you - a discussion took place on the PHP
Foundation slack. I raised a concern that it should be discussed here on
the list for transparency. I am frustrated that it was not.

The short version of that discussion is that PEAR is maintained by
someone else; the PEAR group apparently is separate from the PHP group, as
I understand it.

I don't remember the reason back then but it was basically maintained by
core devs at some point, including myself.

Is that still the case though? I don't think that any current core
developer has access to their GH organizattion. Or do you still have access
/ control to do any changes there and make it deprecated? My main issue
with this RFC is that it's about project that we don't effectively control
and I'm not sure here is anyone who can make any such change to it. From
what I see it's currently maintained by Chuck who, I guess, also control
the project. Or am I wrong?

Alternatively we could potentially propose here move that away from the
PHP domain if we think it's not good for PHP image but that could mean that
we might completely shut it down without any deprecation if there is no
agreement with the current maintainers.

So the ideal case would be to put together some plan how to either get it
deprecated and moved away. But for that we need to first here from the
current maintainers and get them on board.

If here is anyone who has access to PEAR and can comment on this, that
would be great! I also CC'd Chuck as I think it's crucial to get his
opinion on this.

Kind regards,

Jakub

1 month ago by Jakub Zelenka — view source — reply

unread

Hi,

On Fri, Oct 10, 2025 at 2:44 PM Brent Roose brent.roose@jetbrains.com
wrote:

The only thing related to PHP/internals is the fact PEAR is bundled with

PHP and that the PEAR website is a subdomain pear.php.net.

In my opinion, this is sufficient reason to have an RFC for it. A quick
search through the RFCs showed a handful of website-related ones:

https://wiki.php.net/rfc/deprecate-pear-include-composer

https://wiki.php.net/rfc/global_login

https://wiki.php.net/rfc/phpnet-analytics

Then there's the fact that Pear comes bundled with PHP, even more of an
argument that internals have at least something to say about it. Several
RFCs have addressed bundling/unbundling third party plugins before. Again,
a quick search:

https://wiki.php.net/rfc/unbundle_imap_pspell_oci8

https://wiki.php.net/rfc/unbundle_xmlprc

https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx

https://wiki.php.net/rfc/unbundle_recode

To me, and I believe to a significant part of the PHP community, what's
most important is for PHP to acknowledge that composer is its de-facto
standard package manager. This doesn't mean composer cannot operate
independently anymore, but an endorsement would make a lot of sense.

Removing PEAR/PECL from php-src is absolutely fine and such RFC should be
done. As I mentioned, we could also discuss removal from the php.net domain
(move it to the separate domain from pear.php.net). That's what we control
and can do.

But that is not what was proposed in this RFC. It was proposing deprecating
PEAR site and the tool which is quite different. Because this is maintained
outside PHP GitHub organization: https://github.com/pear and from what I
understand even the servers hosting the website are not maintained by us.
But this is just my understanding and maybe I'm missing something and
that's why I asked for people with access to comment here because without
them, such RFC is pointless.

Kind regards,

Jakub

1 month ago by Jakub Zelenka — view source — reply

unread

Hi,

On Fri, Oct 10, 2025 at 2:44 PM Brent Roose brent.roose@jetbrains.com
wrote:

The only thing related to PHP/internals is the fact PEAR is bundled with

PHP and that the PEAR website is a subdomain pear.php.net.

In my opinion, this is sufficient reason to have an RFC for it. A quick
search through the RFCs showed a handful of website-related ones:

https://wiki.php.net/rfc/deprecate-pear-include-composer

https://wiki.php.net/rfc/global_login

https://wiki.php.net/rfc/phpnet-analytics

Then there's the fact that Pear comes bundled with PHP, even more of an
argument that internals have at least something to say about it. Several
RFCs have addressed bundling/unbundling third party plugins before. Again,
a quick search:

https://wiki.php.net/rfc/unbundle_imap_pspell_oci8

https://wiki.php.net/rfc/unbundle_xmlprc

https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx

https://wiki.php.net/rfc/unbundle_recode

To me, and I believe to a significant part of the PHP community, what's
most important is for PHP to acknowledge that composer is its de-facto
standard package manager. This doesn't mean composer cannot operate
independently anymore, but an endorsement would make a lot of sense.

Removing PEAR/PECL from php-src is absolutely fine and such RFC should be
done.

I just gave it an initial try and it's a bit more involved but should be
doable: https://github.com/php/php-src/pull/20124 .

Kind regards,

Jakub

1 month ago by Derick Rethans — view source — reply

unread

Hi,

On Fri, Oct 10, 2025 at 2:44 PM Brent Roose brent.roose@jetbrains.com
wrote:

The only thing related to PHP/internals is the fact PEAR is bundled with

PHP and that the PEAR website is a subdomain pear.php.net.

In my opinion, this is sufficient reason to have an RFC for it. A quick
search through the RFCs showed a handful of website-related ones:

https://wiki.php.net/rfc/deprecate-pear-include-composer

https://wiki.php.net/rfc/global_login

https://wiki.php.net/rfc/phpnet-analytics

Then there's the fact that Pear comes bundled with PHP, even more of an
argument that internals have at least something to say about it. Several
RFCs have addressed bundling/unbundling third party plugins before. Again,
a quick search:

https://wiki.php.net/rfc/unbundle_imap_pspell_oci8

https://wiki.php.net/rfc/unbundle_xmlprc

https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx

https://wiki.php.net/rfc/unbundle_recode

To me, and I believe to a significant part of the PHP community, what's
most important is for PHP to acknowledge that composer is its de-facto
standard package manager. This doesn't mean composer cannot operate
independently anymore, but an endorsement would make a lot of sense.

Removing PEAR/PECL from php-src is absolutely fine and such RFC should
be done. As I mentioned, we could also discuss removal from the
php.net domain (move it to the separate domain from pear.php.net).
That's what we control and can do.

I think these would be my primary actions too:

unbundle pear/pecl from PHP alltogether
not have pear.php.net on the php.net domain.

The latter is because we have no access, and I have no idea what OS it
runs, how it is set up, and whether it even received package and OS
updates in the last decade.

Then somebody else can decide later whether they want to abandon PEAR
(and it's new hosted website).

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

1 month ago by Pierre Joye — view source — reply

unread

Hi Derick,

I think these would be my primary actions too:

unbundle pear/pecl from PHP alltogether

not have pear.php.net on the php.net domain.

The latter is because we have no access, and I have no idea what OS it
runs, how it is set up, and whether it even received package and OS
updates in the last decade.

It was migrated, if my memory serves me correctly, at the same time than
wiki when the compromising attack happened (long ago). I thought you were
involved to it with Bjori? but it may get lost down the road? I lost all
pear/pecl/wiki systems accesses during that time.

My only wish is if we could keep it archived, read-only, and the pgz
accessible as file downloads. That could be done without access tho, but it
requires some more work :)

best,
Pierre

1 month ago by Rowan Tommins [IMSoP] — view source — reply

unread

I think these would be my primary actions too:

unbundle pear/pecl from PHP alltogether

not have pear.php.net on the php.net domain.

The latter is because we have no access, and I have no idea what OS it
runs, how it is set up, and whether it even received package and OS
updates in the last decade.

Then somebody else can decide later whether they want to abandon PEAR
(and it's new hosted website).

I'm not sure whether existing installations would recognise a new domain as the same "channel", even with HTTP redirects in place. So moving to a new domain might be equivalent to shutting down the default channel immediately. And that implies that there is someone out there interested enough in running a new channel, and from the evidence I've seen that seems unlikely.

Maybe I'm wrong, and if we CC a couple of mailing lists, someone will step up; but if not, I think it's perfectly reasonable for the PHP project (i.e. this list) to step in and shut the project down with some reasonable amount of notice.

I don't think we'll do anyone any favours by taking control just long enough to make some config and text changes that disclaim responsibility, then leave any mess to an imaginary "someone else".

Rowan Tommins
[IMSoP]

1 month ago by Sebastian Bergmann — view source — reply

unread

Am 13.10.2025 um 20:01 schrieb Derick Rethans:

I think these would be my primary actions too:

unbundle pear/pecl from PHP alltogether

not have pear.php.net on the php.net domain.

The latter is because we have no access, and I have no idea what OS it
runs, how it is set up, and whether it even received package and OS
updates in the last decade.

Then somebody else can decide later whether they want to abandon PEAR
(and it's new hosted website).
+1

1 month ago by Pierre Joye — view source — reply

unread

Hi,

Hi,

On Fri, Oct 10, 2025 at 2:44 PM Brent Roose brent.roose@jetbrains.com
wrote:

The only thing related to PHP/internals is the fact PEAR is bundled with

PHP and that the PEAR website is a subdomain pear.php.net.

In my opinion, this is sufficient reason to have an RFC for it. A quick
search through the RFCs showed a handful of website-related ones:

https://wiki.php.net/rfc/deprecate-pear-include-composer

https://wiki.php.net/rfc/global_login

https://wiki.php.net/rfc/phpnet-analytics

Then there's the fact that Pear comes bundled with PHP, even more of an
argument that internals have at least something to say about it. Several
RFCs have addressed bundling/unbundling third party plugins before. Again,
a quick search:

https://wiki.php.net/rfc/unbundle_imap_pspell_oci8

https://wiki.php.net/rfc/unbundle_xmlprc

https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx

https://wiki.php.net/rfc/unbundle_recode

To me, and I believe to a significant part of the PHP community, what's
most important is for PHP to acknowledge that composer is its de-facto
standard package manager. This doesn't mean composer cannot operate
independently anymore, but an endorsement would make a lot of sense.

Removing PEAR/PECL from php-src is absolutely fine and such RFC should
be done. As I mentioned, we could also discuss removal from the
php.net domain (move it to the separate domain from pear.php.net).
That's what we control and can do.

I checked the archives to see who had and may still have access, I
found one discussion about compromised pear phar in 2019. It looks
like

Christian Weiske
Chuck Burgess

May have access. And eventually Rasmus?

I added them to the loop here, let see. That may help doing whatever
we decide to do.

--
Pierre

@pierrejoye | http://www.libgd.org

1 month ago by Rowan Tommins [IMSoP] — view source — reply

unread

I checked the archives to see who had and may still have access, I
found one discussion about compromised pear phar in 2019. It looks
like

Christian Weiske
Chuck Burgess

May have access. And eventually Rasmus?

I added them to the loop here, let see. That may help doing whatever
we decide to do.

For the record, I posted a message on Saturday, inviting comments on
this discussion, to four mailing lists (pear-general, pear-dev,
pear-core, and pear-webmaster) plus the pear-group@ address.

So far, there have been no responses.

--
Rowan Tommins
[IMSoP]

1 month ago by Rowan Tommins [IMSoP] — view source — reply

unread

For the record, I posted a message on Saturday, inviting comments on
this discussion, to four mailing lists (pear-general, pear-dev,
pear-core, and pear-webmaster) plus the pear-group@ address.

So far, there have been no responses.

It has now been a week since I sent out my messages. Pierre has also
CC'd Chuck Burgess (twice, first more than two weeks ago) and Christian
Weiske.

There have been no responses.

While it's possible that some interested parties haven't had a chance to
see and respond, all signs point to the same thing: there is no
currently active PEAR Group, and no active PEAR community to elect a new
one.

There is also nobody actively maintaining the website, and nobody likely
to do so if it moved to a new domain.

The pear.php.net website was set up by, and remains the copyright of,
the PHP Group, so arguably they have the final say on its fate.

For now, I think this list is as good a place as any to openly discuss
proposals.

As such, I propose:

We remove all references to PEAR in php-src, such as build options
and installation instructions.
We remove any references in the PHP manual, and add a suggestion to
look at Composer, as an unofficial but popular package manager.
We immediatlely make the Package Proposals system ("PEPr") read-only.
We add a banner in the header on pear.php.net announcing that the
site and channel will shut down at the end of 2026. This can link to a
page which includes tips on installing the same packages using Composer.

Steps 3 and 4 obviously require someone to have access to deploy a new
version of the website. It's not clear exactly who has that access, but
I imagine we can find someone if there is consensus on the changes.

The details of the text can be prepared in public as a pull request to
https://github.com/pear/pearweb/

If, during the next year, someone steps forward to run a fork of the
site on a new domain, we can discuss how to transfer the data. If, as
seems more likely, nobody does so, we can discuss exactly what read-only
archive we are willing to maintain.

I would be willing to either take over Asgrim's RFC or write a new one
with this proposal, so that we can confirm consensus with a vote.

--
Rowan Tommins
[IMSoP]

1 month ago by Jakub Zelenka — view source — reply

unread

Hi,

On Sun, Oct 26, 2025 at 2:38 PM Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
wrote:

As such, I propose:

We remove all references to PEAR in php-src, such as build options
and installation instructions.

I have already started this in https://github.com/php/php-src/pull/20124
but it's that simple as it got a bit rooted to the php-src. It will take
some time though. I might just merge it if there are no objection so it
might not even need RFC unless there are any objection.

We remove any references in the PHP manual, and add a suggestion to

look at Composer, as an unofficial but popular package manager.

That's a good and I don't think we even need RFC for this either.

We immediatlely make the Package Proposals system ("PEPr") read-only.

We add a banner in the header on pear.php.net announcing that the
site and channel will shut down at the end of 2026. This can link to a
page which includes tips on installing the same packages using Composer.

Steps 3 and 4 obviously require someone to have access to deploy a new
version of the website. It's not clear exactly who has that access, but
I imagine we can find someone if there is consensus on the changes.

Well I guess Chuck is the only person who can do that so without any
response from him, there is not much we can do. I'm not sure if it makes
much sense doing RFC about something that we cannot do. I mean it all
really depends if he is happy to do that. But maybe it can be just some
sort of a symbolic thing that sends a signal.

Kind regards

Jakub

1 month ago by Pierre Joye — view source — reply

unread

Hi,

Hi James,

Apparently, this RFC has been withdrawn in the meantime. I would like
to know why. :)

I absolutely agree with you - a discussion took place on the PHP Foundation slack. I raised a concern that it should be discussed here on the list for transparency. I am frustrated that it was not.

The short version of that discussion is that PEAR is maintained by someone else; the PEAR group apparently is separate from the PHP group, as I understand it.

I don't remember the reason back then but it was basically maintained by core devs at some point, including myself.

Is that still the case though?

For the packages repositories hosted (git, ex-svn),yes, see
https://github.com/pear. The idea of the group was to be able to take
over abandoned but widely used packages, define what licenses are
allowed and other related areas. The packages repositories not hosted
on php's repos are still where they used to be, if the service still
exists.

I checked my archives. For the record, it was done this way as there
were strong arguments, and opinions, about php being only about the
language itself and nothing else, etc. Things change here and there.

I don't think that any current core developer has access to their GH organizattion. Or do you still have access / control to do any changes there and make it deprecated? My main issue with this RFC is that it's about project that we don't effectively control and I'm not sure here is anyone who can make any such change to it. From what I see it's currently maintained by Chuck who, I guess, also control the project. Or am I wrong?

I do have access, I did not check the role tho'.

Alternatively we could potentially propose moving that away from the PHP domain if we think it's not good for PHP image but that could mean that we might completely shut it down without any deprecation if there is no agreement with the current maintainers.

I don't see a point in moving the DNS entry away, that makes little
sense. A few steps toward shutdown permanently, once or if agreed to:

mail the pear-dev ML and maintainers about the plan
disable any new releases, some are still released
(f.e.https://pear.php.net/package/Log/)
add (future) service shutdown to the pear home page and/or in the
site header
archive releases somewhere (static's php.net maybe?)
Once shutdown's date is reached, static page with link to the
archive for the releases (for the few people still using them)

The removal for php's dists is obviously a good first step but I would
not do it in minor releases tho'. I have seen internal projects here
and there still running (php8 too :), and using pear, let's give them
a last bit of time to see the light maybe?

As of pecl, the same could be applied. I do not know for PIE, but if
needed, pickle has the code to migrate package(1|2).xml, target needs
to be changed then to what PIE uses now, that's something maintainers
of exts can do. Unmaintained ones can go to the archives as well.

best,

Pierre

@pierrejoye | http://www.libgd.org

1 month ago by Rowan Tommins [IMSoP] — view source — reply

unread

For the packages repositories hosted (git, ex-svn),yes, see
https://github.com/pear. The idea of the group was to be able to take
over abandoned but widely used packages, define what licenses are
allowed and other related areas. The packages repositories not hosted
on php's repos are still where they used to be, if the service still
exists.

An additional point worth noting is that all the packages in that GitHub org are published to both PEAR and Packagist. A few may not have been tested in Composer projects, but fixes are likely to be easy as long as someone's available to tag a new release - I seem to remember raising a small PR to fix some autoloading or dependency issues for something I needed.

For users not ready to adopt a full Composer per-project workflow, we could recommend to use its global install mode, e.g.

Replace:
pear install HTML_Template_IT
With:
composer global install pear/html_template_it

Then all that should need fixing is include paths or autoloader setup in the application.

Rowan Tommins
[IMSoP]

1 month ago by Jakub Zelenka — view source — reply

unread

Hi,

Hi,

On Fri, Oct 10, 2025 at 12:01 PM Pierre Joye pierre.php@gmail.com
wrote:

Hi James,

On Fri, Oct 10, 2025, 3:29 PM James Titcumb titcumbjames@gmail.com
wrote:

Apparently, this RFC has been withdrawn in the meantime. I would like
to know why. :)

I absolutely agree with you - a discussion took place on the PHP
Foundation slack. I raised a concern that it should be discussed here on
the list for transparency. I am frustrated that it was not.

The short version of that discussion is that PEAR is maintained by
someone else; the PEAR group apparently is separate from the PHP group, as
I understand it.

I don't remember the reason back then but it was basically maintained
by core devs at some point, including myself.

Is that still the case though?

For the packages repositories hosted (git, ex-svn),yes, see
https://github.com/pear. The idea of the group was to be able to take
over abandoned but widely used packages, define what licenses are
allowed and other related areas. The packages repositories not hosted
on php's repos are still where they used to be, if the service still
exists.

I checked my archives. For the record, it was done this way as there
were strong arguments, and opinions, about php being only about the
language itself and nothing else, etc. Things change here and there.

Ok so I guess the current status is kind on unknown... :) But as noted by
Rowan in other email, there's a mention of the PEAR Group that is the
governing body of the project although seems expired so I have really no
idea what the governance there is and if the RFC process should have any
power over that project.

I don't think that any current core developer has access to their GH
organizattion. Or do you still have access / control to do any changes
there and make it deprecated? My main issue with this RFC is that it's
about project that we don't effectively control and I'm not sure here is
anyone who can make any such change to it. From what I see it's currently
maintained by Chuck who, I guess, also control the project. Or am I wrong?

I do have access, I did not check the role tho'.

I guess this is really the crucial part here. Are you able / willing /
comfortable to potentially update the website or the tool if we approve the
RFC about deprecation and are you sure that the current maintainer is ok
with that (basically respect RFC as the governance method for PEAR)?

Alternatively we could potentially propose moving that away from the PHP
domain if we think it's not good for PHP image but that could mean that we
might completely shut it down without any deprecation if there is no
agreement with the current maintainers.

I don't see a point in moving the DNS entry away, that makes little
sense. A few steps toward shutdown permanently, once or if agreed to:

mail the pear-dev ML and maintainers about the plan

disable any new releases, some are still released

(f.e.https://pear.php.net/package/Log/)
3. add (future) service shutdown to the pear home page and/or in the
site header
4. archive releases somewhere (static's php.net maybe?)
5. Once shutdown's date is reached, static page with link to the
archive for the releases (for the few people still using them)

Ok but this assumes that we are able to do 2 and 3.

The removal for php's dists is obviously a good first step but I would
not do it in minor releases tho'. I have seen internal projects here
and there still running (php8 too :), and using pear, let's give them
a last bit of time to see the light maybe?

If we are talking just about removing everything in php-src, then I don't
think it's issue to get rid of it in 8.6 but we should for sure have RFC to
decide it.

Kind regards

Jakub

1 month ago by Pierre Joye — view source — reply

unread

Ok so I guess the current status is kind on unknown... :) But as noted by Rowan in other email, there's a mention of the PEAR Group that is the governing body of the project although seems expired so I have really no idea what the governance there is and if the RFC process should have any power over that project.

I don't think that any current core developer has access to their GH organizattion. Or do you still have access / control to do any changes there and make it deprecated? My main issue with this RFC is that it's about project that we don't effectively control and I'm not sure here is anyone who can make any such change to it. From what I see it's currently maintained by Chuck who, I guess, also control the project. Or am I wrong?

I do have access, I did not check the role tho'.

I guess this is really the crucial part here. Are you able / willing / comfortable to potentially update the website or the tool if we approve the RFC about deprecation and are you sure that the current maintainer is ok with that (basically respect RFC as the governance method for PEAR)?

To make it simple, PEAR is part of the PHP projects. There was a
separate group to do the admin work, security releases when needed,
sync with php releases to bundle it, etc.

For the purpose of fading out pear, and, more importantly, pecl, we
can handle it here using the normal RFC flow. Most of the group
members are barely (f.e. me) or not active at all anymore.

mail the pear-dev ML and maintainers about the plan

disable any new releases, some are still released
(f.e.https://pear.php.net/package/Log/)

add (future) service shutdown to the pear home page and/or in the
site header

archive releases somewhere (static's php.net maybe?)

Once shutdown's date is reached, static page with link to the
archive for the releases (for the few people still using them)

Ok but this assumes that we are able to do 2 and 3.

And 1. :)

The removal for php's dists is obviously a good first step but I would
not do it in minor releases tho'. I have seen internal projects here
and there still running (php8 too :), and using pear, let's give them
a last bit of time to see the light maybe?

If we are talking just about removing everything in php-src, then I don't think it's issue to get rid of it in 8.6 but we should for sure have RFC to decide it.

I agree, easy to greap the phar when needed but communication is key
to avoid bad surprises. Maybe a pre warning in the upcoming 8.5
release.

Best,

Pierre

@pierrejoye | http://www.libgd.org

1 month ago by Jakub Zelenka — view source — reply

unread

Ok so I guess the current status is kind on unknown... :) But as noted
by Rowan in other email, there's a mention of the PEAR Group that is the
governing body of the project although seems expired so I have really no
idea what the governance there is and if the RFC process should have any
power over that project.

I don't think that any current core developer has access to their GH
organizattion. Or do you still have access / control to do any changes
there and make it deprecated? My main issue with this RFC is that it's
about project that we don't effectively control and I'm not sure here is
anyone who can make any such change to it. From what I see it's currently
maintained by Chuck who, I guess, also control the project. Or am I wrong?

I do have access, I did not check the role tho'.

I guess this is really the crucial part here. Are you able / willing /
comfortable to potentially update the website or the tool if we approve the
RFC about deprecation and are you sure that the current maintainer is ok
with that (basically respect RFC as the governance method for PEAR)?

To make it simple, PEAR is part of the PHP projects. There was a
separate group to do the admin work, security releases when needed,
sync with php releases to bundle it, etc.

For the purpose of fading out pear, and, more importantly, pecl, we
can handle it here using the normal RFC flow. Most of the group
members are barely (f.e. me) or not active at all anymore.

Ok, if you say so and can make such change, I think we should put this RFC
back for discussion.

Kind regards

Jakub

1 month ago by Nick — view source — reply

unread

For the purpose of fading out pear, and, more importantly, pecl, we
can handle it here using the normal RFC flow. Most of the group
members are barely (f.e. me) or not active at all anymore.

Hey Pierre,

I understand you have access to the site. Because of that I answer here.

The proposals with the IDs 710, 711, 708, 83, 662, 700 contain (mostly) online casinos links.
Some of the proposals have the same account as last edit in their change log.
Perhaps it makes sense to consider to disable editing old and adding new proposals. The last real proposal was in 2013.
The newest three proposals sole purpose seems to be to get links in; for instance 710 is an exact copy of 83 from 21 years ago.

Cheers
Nick

1 month ago by Rowan Tommins [IMSoP] — view source — reply

unread

The short version of that discussion is that PEAR is maintained by
someone else; the PEAR group apparently is separate from the PHP
group, as I understand it.

The PEAR website has a list of members of the PEAR Group, but says that
they were elected for a one-year term in 2009:
https://pear.php.net/group/ I'm not sure whether elections were
abandoned after that, or if the page was just not updated.

The "News" page ends in 2007, but links to a now-defunct WordPress blog,
which seems to have been maintained until 2018, after which I can't find
any official announcements at all:
https://web.archive.org/web/20181102164127/https://blog.pear.php.net/

The "pear-dev" list has had 3 threads this year, only 1 of which
actually got a helpful response:
https://news-web.php.net/group.php?group=php.pear.dev The "pear-general"
list has had only 1 message this year, which went unanswered:
https://news-web.php.net/group.php?group=php.pear.general

The RSS activity feeds are mostly broken, but comparing archived package
lists, I think the most recently approved package was Date_Holidays_Peru
in 2019; and before that, File_Therion in 2016.

I also had a look through the list of around 80 third-party channels
here: https://pear.php.net/channels/ Other than pear.php.net and
pecl.php.net, I could find only 8 that looked like they might still be
usable.

The remainder are either non-existent/squatted domains, or projects
whose installation instructions refer only to Composer, or occasionally
PHAR downloads.

There are still references to "PEAR2" and "Pyrus" here and there, but
https://pear2.php.net doesn't even resolve

Everything points to the entire project being essentially unmaintained:
there are people here and there keeping the lights on, but little else.

Since it was for a long time promoted as the official package manager
for PHP, I think the PHP project has some responsibility - imagine, for
instance, if there was a security breach of pear.php.net.

I think as well as removing references in the manual and php-src, we
should at minimum work to add disclaimers to the site that it is no
longer officially endorsed by PHP, and perhaps pointing to a migration
guide to Composer.

--
Rowan Tommins
[IMSoP]