Hi,

On Sat, Oct 11, 2025 at 11:32 AM Pierre Joye <[email protected]> wrote:

> On Fri, Oct 10, 2025 at 5:36 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?
>
> For the packages repositories hosted (git, ex-svn),yes, see
> https://github.com/pear. The idea of the group was to be able to take
> over abandoned but widely used packages, define what licenses are
> allowed and other related areas. The packages repositories not hosted
> on php's repos are still where they used to be, if the service still
> exists.
>
> I checked my archives. For the record, it was done this way as there
> were strong arguments, and opinions, about php being only about the
> language itself and nothing else, etc. Things change here and there.
>
>
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)?


>
> > Alternatively we could potentially propose moving 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.
>
> I don't see a point in moving the DNS entry away, that makes little
> sense. A few steps toward shutdown permanently, once or if agreed to:
>
> 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.


>
> 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.

Kind regards

Jakub

Reply via email to