# [RFC] End PEAR Project Endorsement - Thread: https://externals.io/message/132358 - Original archive: https://news-web.php.net/php.internals/132358 - Started by Nick Sdot on 2026-08-27T03:36:50+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #132358 — Nick Sdot — 2026-08-27T03:36:50+00:00 URL: https://externals.io/message/132358#132358 Hey internals, I would like to open the discussion to "End PEAR Project Endorsement": https://wiki.php.net/rfc/end_pear_endorsement Over the last months the state of PEAR was several times discussed here. Multiple people reached out to PEAR via direct and official channels; no finite solution could be found. About three months ago I started going through all previous discussions and old (not voted) RFC attempts; I don't see an unsolvable blocker. Hence, I drafted this RFC, and created a static mirror of the PEAR website (to keep the CLI working; infra team was consulted). After that, it once again was tried to find a cooperative solution (foundation also aware), and things given time to play out another two months -- with no finite result. PEAR was a great effort, and we can all be grateful to the people who invested their time to make it happen. However, times changed -- people use Composer. The PEAR site is partly broken, spammed, has very little activity, and as of recent happens to be unmaintained. We win nothing by further stalling a decision; I believe we should stop the endorsement for PEAR. This RFC attempts to address all open questions from previous discussions, and seeks to offer a balanced and practical solution. --- Cheers Nick --- ## #132362 — Rowan Tommins [IMSoP] — 2026-08-27T13:17:26+00:00 URL: https://externals.io/message/132358#132362 · In reply to: #132358 Hi Nick, >Hey internals, > >I would like to open the discussion to "End PEAR Project Endorsement": >https://wiki.php.net/rfc/end_pear_endorsement Thanks for putting this together and moving the conversation forward. I wholeheartedly support this course of action. >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: 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. - 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? Thanks again - and thanks also to everyone who has contributed to PEAR in the past, and everyone who has tried to reach someone to bring it back to life. Regards, Rowan Tommins [IMSoP] --- ## #132367 — Nick Sdot — 2026-08-27T16:23:30+00:00 URL: https://externals.io/message/132358#132367 · In reply to: #132362 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 --- ## #132440 — Derick Rethans — 2026-09-07T09:03:46+00:00 URL: https://externals.io/message/132358#132440 · In reply to: #132362 > > > > […] > > 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: > > > 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 --- ## #132446 — Nick Sdot — 2026-09-07T19:24:03+00:00 URL: https://externals.io/message/132358#132446 · In reply to: #132358 Hey everyone, > > I would like to open the discussion to "End PEAR Project Endorsement": > https://wiki.php.net/rfc/end_pear_endorsement > 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. This is great, because A) everyone involved agrees on the goal and B) this makes the vote a formality. He said he doesn't read here, but anyway from me a thank you to Chuck! That said, I would soon bring this to vote -- so this mail could be seen as my "intend to vote" mail. 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?). The question is, when the "Proposal" section remains explicitly unchanged does it count as a minor change? Given the state of the PEAR website, and that the vote will be a formality, it would be pity to have to wait another two weeks to open the vote. Thoughts? Since this is a policy question I added Tim in CC. -- Cheers Nick --- ## #132447 — Larry Garfield — 2026-09-07T20:37:15+00:00 URL: https://externals.io/message/132358#132447 · In reply to: #132446 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. --- ## #132448 — Rowan Tommins [IMSoP] — 2026-09-07T22:17:28+00:00 URL: https://externals.io/message/132358#132448 · In reply to: #132446 > > 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] --- ## #132449 — Nick Sdot — 2026-09-08T05:03:08+00:00 URL: https://externals.io/message/132358#132449 · In reply to: #132448 Hey Rowan, > > 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? > That was brought up. Unfortunately, the user accounts are gone. Hence, the bug data cannot be provided. > > […] > > 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. Chuck is the one who had the authority to archive the repos in the PEAR GitHub organisation. Also, allow me to highlight the "Non-goals" section of the RFC: > The goal is not to take over the governance of the independent PEAR package ecosystem. *If an independent PEAR team wants to continue PEAR as an active project, they remain free to do so under domains they control.* > > 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. That too, yes. > > 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, Rowan! I am fine with that. One thing I'd add: I think having the "locked PEAR" is nice. Not sure about the favicon change. It's will be a The PHP Group hosted archive, not the successor of the PEAR project. Keeping the PHP favicon feels more sound to me, personally. But I happily leave that decision to you and others (infra team?). --- Cheers Nick --- ## #132450 — Rowan Tommins [IMSoP] — 2026-09-08T07:55:37+00:00 URL: https://externals.io/message/132358#132450 · In reply to: #132449 >Hey Rowan, > > > > […] > >That was brought up. Unfortunately, the user accounts are gone. Hence, the bug data cannot be provided. That's a pity. In hindsight, if we'd acted sooner we could have rescued that content before it disappeared; but we couldn't have known that. >Chuck is the one who had the authority to archive the repos in the PEAR GitHub organisation. I would make a distinction between technical *ability* and moral *authority*. For example, many people have access to commit to the php-src repo; they have the *ability* to make whatever changes they want, but they only have the *authority* to make changes within our agreed process. In this case, Derick has the *ability* to repoint the DNS for pear.php.net, but holding this discussion and an RFC vote is a way to grant *authority*. Chuck has apparently been keeping parts of the PEAR project running after others drifted off, and I thank him for that. If he *disagreed* with the plan, that would have been significant - but so would anyone replying on the four PEAR mailing lists I posted to last October. Hearing that he is in favour is welcome, but it doesn't change much in terms of moral authority. >Thanks, Rowan! I am fine with that. One thing I'd add: I think having the "locked PEAR" is nice. Not sure about the favicon change. It's will be a The PHP Group hosted archive, not the successor of the PEAR project. Keeping the PHP favicon feels more sound to me, personally. But I happily leave that decision to you and others (infra team?). Yes, I kept the favicon part in a separate commit in case it was controversial; feel free to cherry-pick the main styling and skip that one if you prefer. Cheers, Rowan Tommins [IMSoP] --- ## #132451 — tim@bastelstu.be — 2026-09-08T08:05:02+00:00 URL: https://externals.io/message/132358#132451 · In reply to: #132447 Hi > 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. I agree. This change in circumstances seems substantial enough that it might cause folks to vote differently, without changing the actual proposal. Best regards Tim Düsterhus --- ## #132453 — Derick Rethans — 2026-09-08T08:27:38+00:00 URL: https://externals.io/message/132358#132453 · In reply to: #132449 >Hey Rowan, > > > > […] >Thanks, Rowan! I am fine with that. One thing I'd add: I think having the "locked PEAR" is nice. Not sure about the favicon change. It's will be a The PHP Group hosted archive, not the successor of the PEAR project. Keeping the PHP favicon feels more sound to me, personally. But I happily leave that decision to you and others (infra team?). I don't care what the favicon is, as long as there is one. cheers Derick --- ## #132489 — Nick Sdot — 2026-09-14T04:14:16+00:00 URL: https://externals.io/message/132358#132489 · In reply to: #132446 Hey everyone, > However, there is one detail I would want to double check with you > all. The RFC currently has this sentence: > > > […] > 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 --- ## #132496 — Juliette Reinders Folmer — 2026-09-14T11:18:18+00:00 URL: https://externals.io/message/132358#132496 · In reply to: #132489 > 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. That's amazing news and very very welcome! Thank you for coordinating with Chuck and thanks Chuck for unearthing the data! Smile, Juliette --- ## #132497 — Jakub Zelenka — 2026-09-14T11:57:02+00:00 URL: https://externals.io/message/132358#132497 · In reply to: #132358 Hi, > Hey internals, > > I would like to open the discussion to "End PEAR Project Endorsement": > https://wiki.php.net/rfc/end_pear_endorsement > > 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. Kind regards, Jakub --- ## #132501 — Nick Sdot — 2026-09-14T16:31:54+00:00 URL: https://externals.io/message/132358#132501 · In reply to: #132497 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 --- ## #132502 — Jakub Zelenka — 2026-09-14T20:39:02+00:00 URL: https://externals.io/message/132358#132502 · In reply to: #132501 Hey, > Hey Jakub, > > > > […] > > > 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? > > Sounds good, thanks > Also related: Daniel recently opened > https://github.com/php/php-src/pull/23634 which targets 8.2. > > I'm aware - we were just discussing it between RM's Kind regards, Jakub --- ## #132577 — Nick Sdot — 2026-09-21T14:30:36+00:00 URL: https://externals.io/message/132358#132577 · In reply to: #132358 Hey everyone, > I would like to open the discussion to "End PEAR Project Endorsement": > https://wiki.php.net/rfc/end_pear_endorsement If there are no objections I would bring this to vote on 2026-09-28. --- Cheers Nick --- ## #132769 — Nick Sdot — 2026-10-02T05:14:45+00:00 URL: https://externals.io/message/132358#132769 · In reply to: #132577 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