Re: [RFC] End PEAR Project Endorsement

From: Date: Mon, 07 Sep 2026 09:03:46 +0000
Subject: Re: [RFC] End PEAR Project Endorsement
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-132440@lists.php.net to get a copy of this message
On Thu, 27 Aug 2026, Rowan Tommins [IMSoP] wrote: > On 27 August 2026 04:36:50 BST, Nick Sdot <php@nicksdot.dev> wrote: > > >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

« previous php.internals (#132440) next »