[RFC] End PEAR Project Endorsement View as Markdown

Thanks Rowan,

One of the points he discusses is that freezing a channel rather than taking it offline means that security vulnerabilities are also frozen in place, with no way to supersede them for anyone still using the old tooling.

I think readonly is probably the right approach in this case at least in the short term, but actively sunsetting later is maybe something to consider.

Agreed. The infra team also would prefer sunsetting at some point; it's
in the future scope of the RFC.

Also, it's mentioned in the RFC but probably worth to be highlighted
here: only 6 packages are still publishing to PEAR.

• 3/6 are PEAR infra packages
• 2/6 are non-PEAR infra packages (but by a PEAR Group member) were
  recently marked as unmaintained

Which makes it exactly one single independent package that is still
maintained (legend!):
Net_SMTP (which is also on Packagist).

I think we can safely say that security is not a very pressing concern
in this very situation; and that keeping the CLI alive for a while is to
demonstrate good manners rather than serving high demand. :)

My only other specific comment is that looking at the draft mirror, only some of the bug reports seem to be there. I'm guessing this is because of the problem Juliette reported a while ago that many of them have started showing an error about unconfirmed email addresses.

I wonder if being logged in as a package maintainer would be enough to see them, or if they're gone for good unless someone with admin access appears. Does anyone have an account to check?

Correct. Only bugs that are accessible on the PEAR website are in the
archive. Rather than archiving and linking error pages with no relevant
content, I omitted those. Saves resources and clicks. Some of the pages
could be recovered from year 2007 snapshots on archive.org, but that's
quite some extra work. Since the PEAR site itself no longer has those
pages, it’s probably:

A) reasonable to expect anyone who wants to look up such old bugs to
visit archive.org themselves
B) not the job of the archive to me more complete than its source;
hence, out of scope for the RFC

That said, if an admin would provide a database dump I am keen to
backfill missing bugs at any time (before or after the archive goes online).

--

Cheers
Nick

We win nothing by further stalling a decision; I believe we should
stop the endorsement for PEAR.

I think this is the key: a lot of the comments on previous discussions
were about "giving a chance" for one or other individual or group to
revive the website. Multiple attempted contacts were made, and many
months have gone by, with nobody reporting a positive result.

If that's not long enough, how long is? If the site stays alive in its
current state for 10 years, it will continue to be exploited by
spammers and probably worse. That's not in anyone's interest.

Coincidentally, Andrew Nesbitt, who writes tooling and analysis
comparing different packaging systems, wrote a recent post about
approaches to sunsetting:
https://nesbitt.io/2026/06/23/sunsetting-a-package-manager.html

One of the points he discusses is that freezing a channel rather than
taking it offline means that security vulnerabilities are also frozen
in place, with no way to supersede them for anyone still using the old
tooling.

I think readonly is probably the right approach in this case at least
in the short term, but actively sunsetting later is maybe something to
consider.

I agree. I think we should commit to leaving it on for a specified
amount only (a year), and then also turn off the archival variant of the
site. We can move a tarball onto our museum.php.net property for
archeologists.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social

I would consider that a Minor change, so 1 week cool down, and you can post an intent to vote basically any time during that week as it has a 1 week allowance.

Got news. The tl;dr is that Chuck Burgess from PEAR got in touch with
me (and also Elizabeth from the foundation). He did let me know that
he is good with looking at sunsetting the website and removing PEAR
from PHP source.

That's great that someone finally got in touch. Does he have access to
provide a database dump, so we can fill in the missing bug data?

This is great, because A) everyone involved agrees on the goal and B)
this makes the vote a formality.

Unless you know something I don't, Chuck's agreement is just one vote,
not any kind of final authority. He is listed at
https://pear.php.net/group/ as one of eight members of "the PEAR Group",
so in theory the other seven could decide they want to continue the
project. In fact, the Group was supposed to be re-elected annually, so
even their collective authority is shaky if anyone really wanted to
replace them.

In practice, he's the only person involved who anyone has managed to
track down, and even that took several months, so I think we're safe to
say nobody's that interested.

In other news, I noticed the mirror you created didn't yet have much
styling, so I've put together a quick PR copying in the colours and
basic styles from the existing site, plus an idea I had for a "locked
PEAR" logo: https://github.com/NickSdot/pear/pull/1

Thanks again,

--
Rowan Tommins
[IMSoP]

Hey everyone,

However, there is one detail I would want to double check with you
all. The RFC currently has this sentence:

Attempts to find solutions with PEAR maintainers, directly and
through official channels, did not lead to results.

Given that Chuck now got in touch and is in favour, I am not happy
leaving this sentence unchanged in the RFC. I'd much rather remove it
(or strike it and amend the agreement?).

I made the following changes to the RFC:

1. Removed the mentioned sentence and added a section to reflect the new
   situation.
2. Removed "Future Scope" and added explicit timeline to the proposal
   (coordinated with Derick).

This is a major change, which means the discussion remains open until at
least 2026-09-27.

Additionally, there is another good news. Chuck from PEAR made an effort
to recover the missing bug pages and was successful. Thankfully, he now
can and will provide us with everything we need for the archive.

Cheers
Nick

Hey Jakub,

Shouldn't we first unbundle it from php-src and then move to the
static archive or is the pear install (which I think is used in
Windows build in some cases) still work?

I plan to resume the work on that PR in October or November when I
should have more time but it would be good if someone could check if
that move to static archive cannot break anything in php-src.

With help from Derick I looked into it, my understanding is that we can
flip the switch without first unbundling as long as we don't break the
resource URLs (XML, packages, phars). The static archive will keep
providing the required resources under pear.php.net/* (eg.
go-pear.phar) and pear.php.net/rest/*; just no longer from the
dynamic code base that powers the website currently. The domain will not
change.

That said, the vote -- depending on when it starts -- will not end
before mid October. The current archive is still PoC, and I will have
some work before switching. Realistically, we will not land anything
before November. So that aligns with your own timeline and we will have
time to coordinate. Sounds good?

Also related: Daniel recently opened
https://github.com/php/php-src/pull/23634 which targets 8.2.

Cheers
Nick

Hey everyone,

If there are no objections I would bring this to vote on 2026-09-28.

Unfortunately, I got busy and missed to open the vote in time. According
to policy I have to re-announce my intent to vote: I will open it within
the next seven days.

Sorry for the extra mail!

Cheers
Nick