> > 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. Brent On Fri, Oct 10, 2025 at 12:39 PM Jakub Zelenka <[email protected]> wrote: > Hi, > > On Fri, Oct 10, 2025 at 12:01 PM Pierre Joye <[email protected]> wrote: > >> Hi James, >> >> On Fri, Oct 10, 2025, 3:29 PM James Titcumb <[email protected]> >> wrote: >> >>> On Thu, 9 Oct 2025 at 21:39, Christoph M. Becker 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 >
