On Sun, Oct 12, 2025 at 2:13 AM Jakub Zelenka <[email protected]> wrote:
> 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. >> 1. mail the pear-dev ML and maintainers about the plan >> >> 2. 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. 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
