Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128816 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 6C4301A00BC for ; Sat, 11 Oct 2025 19:13:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1760209996; bh=HKJVgPGDrf5WDI3N3fPhoCxss5CvMex3qAm2dqoDcsE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=n1ibfja8WsYrgmE7n3uzaUAFaG+hHbTtG8C4t0qTLk60ZTWjst8RXxAINgLuAGdjI bz+Czd0IRngCTZ9EQXbZ4m2TG8eSSjExz8rCp4TbqBD8nQYWQHdD+U9GbCc8IR/8s6 L9RT2GA6H6nue0qAwCOoepMTtPGwk8VrZ6ouKD5NjuirxTjaGXcjQyXNGLP9CxlM/L AeS1E1Y4hdDmHc6s5LgckDpb4XwlgCa890LZEFp90Wn4jbPjq6WZfw/Ot2ixkarjqq lH5/rZ0ylO0INZ9q/5hMrPcmqmFN+o/bU7olNLsBhwMkuqCQUQbMrte0blrwHFdKM7 TW9JFtLxUfa1A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0963E180209 for ; Sat, 11 Oct 2025 19:13:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=BAYES_50,DMARC_NONE, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-oo1-f52.google.com (mail-oo1-f52.google.com [209.85.161.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 11 Oct 2025 19:13:14 +0000 (UTC) Received: by mail-oo1-f52.google.com with SMTP id 006d021491bc7-64442ff55c2so865485eaf.2 for ; Sat, 11 Oct 2025 12:13:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760209989; x=1760814789; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PI8y0+oGPUYDYadUKxN5vfjZbGL0r5lN7we2/SSD+po=; b=PuSajT2kY77XDn+KfnYamGrqv8LLHfbxYR2dsOGZlEtZvwTcRXw/o08cAfu2D+Al8H DNeBbQgDfDpfSF3BHGnT5X27e32pmblWgG/3NCS84Kk44T89kH73CmI9iDmkXKUynx9G mVWulQXibwfxMB/kbFHo8/TBDK0bfoz0UQhCK/w8gkEmQ59shRUzvV4QlEepLhzBu+LU czsvBOU/xwZ3FCypcOiirE6AzDxnQA7dXjy8GSeE7QEUBkwm4T1vCvDZHaSO4BzIoWZH OkhkbRL+NWJP7fOv7t68YPelQFtVayzJ+AzrldJmBXmToWFaiZ/UQ9BZ0+mBfkspjW4W bEOA== X-Forwarded-Encrypted: i=1; AJvYcCVFtM278U1KCVnzgQI7YoNTY+tJohTg1hY1DNtJLtDAmQ/Xpu9ZftUxDgVNZP8FpP3Cjtc37uuBMZc=@lists.php.net X-Gm-Message-State: AOJu0YzVaENGw9lBRIFEURl+P3Ye+GqMPeFbwgO2IwRInkZW8YXxCieo VQ1aQF+0jxFvnz/a+ejxYi51Vj0myBXJGBwfwQA2AXdV15YreP2PsprMPyfXfSJueBul8PlnYYL ndNaxq4ipGPES7D+8b0Xzi//sNQL8BuCiNQ== X-Gm-Gg: ASbGnctJ3soEp1lP8pnPNDnTy1GkLIlTiykWYtogHZ1Sf9/E8C3eFPKC3KuPOETFrfL +wq1lZbrgWM2MgHOeIQEEc44H33YPQlLKvjbKt7eMIWRNvM0gZmM7jv9bPvPqj6DHs2EUNCX7xQ rTzJ6kh7naY5OIKtEKdZcJ+sZxHbbs6OrRRpAgpCxIbbkDJ9Uwj77PGolMSmAXOoY9EIB47Qd+N TckpqkAWqVE4p2534/LqDZYlw== X-Google-Smtp-Source: AGHT+IH/s+IT0rfP7Zsly9lEiLZtAOwQ4afh37wIcg+PtzlNDWmSeQINhHVn0LX44YxO1Be2ZH0d5kU+YA6J+BNFBqQ= X-Received: by 2002:a05:6870:910c:b0:345:50af:a674 with SMTP id 586e51a60fabf-3c0f8daf583mr6947754fac.36.1760209988871; Sat, 11 Oct 2025 12:13:08 -0700 (PDT) Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 11 Oct 2025 21:12:57 +0200 X-Gm-Features: AS18NWCGVmAMRxsRQLvjcTntXRTLvcBSaL7kuuKdFtGF-6nvp-JTz-bL4uPUzWI Message-ID: Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate PEAR and recommend Composer To: Pierre Joye Cc: james@asgrim.com, "Christoph M. Becker" , PHP Internals List , ashnazg@php.net Content-Type: multipart/alternative; boundary="0000000000001deb3c0640e6d3ba" From: bukka@php.net (Jakub Zelenka) --0000000000001deb3c0640e6d3ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Sat, Oct 11, 2025 at 11:32=E2=80=AFAM Pierre Joye = wrote: > On Fri, Oct 10, 2025 at 5:36=E2=80=AFPM Jakub Zelenka wro= te: > > > > Hi, > > > > On Fri, Oct 10, 2025 at 12:01=E2=80=AFPM Pierre Joye > wrote: > >> > >> Hi James, > >> > >> On Fri, Oct 10, 2025, 3:29 PM James Titcumb > wrote: > >>> > >>> On Thu, 9 Oct 2025 at 21:39, Christoph M. Becker wrote: > >>>> > >>>> Apparently, this RFC has been withdrawn in the meantime. I would li= ke > >>>> 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, a= s > 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 PH= P > domain if we think it's not good for PHP image but that could mean that w= e > 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 --0000000000001deb3c0640e6d3ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Sat, Oct 11, 2025 at 11:3= 2=E2=80=AFAM Pierre Joye <pierre= .php@gmail.com> wrote:
On Fri, Oct 10, 2025 at 5:36=E2=80=AFPM Jakub Zelenka <bukka@php.net> wrote= :
>
> Hi,
>
> On Fri, Oct 10, 2025 at 12:01=E2=80=AFPM Pierre Joye <pierre.php@gmail.com> w= rote:
>>
>> Hi James,
>>
>> On Fri, Oct 10, 2025, 3:29 PM James Titcumb <titcumbjames@gmail.com> wr= ote:
>>>
>>> On Thu, 9 Oct 2025 at 21:39, Christoph M. Becker wrote:
>>>>
>>>> Apparently, this RFC has been withdrawn in the meantime.= =C2=A0 I would like
>>>> to know why. :)
>>>
>>>
>>> I absolutely agree with you - a discussion took place on the P= HP 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 maintaine= d 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 mai= ntained by core devs at some point, including myself.
>>
>
> Is that still the case though?

For the packages repositories hosted (git, ex-svn),yes, see
ht= tps://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 ki= nd on unknown... :) But as noted by Rowan in other email, there's a men= tion of the PEAR Group that is the governing body of the project although s= eems expired so I have really no idea what the governance there is and if t= he 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 t= here and make it deprecated? My main issue with this RFC is that it's a= bout project that we don't effectively control and I'm not sure her= e is anyone who can make any such change to it. From what I see it's cu= rrently 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 par= t here. Are you able / willing / comfortable to potentially update the webs= ite or the tool if we approve the RFC about deprecation and are you sure th= at the current maintainer is ok with that (basically respect RFC as the gov= ernance method for PEAR)?
=C2=A0

> Alternatively we could potentially propose moving that away from the P= HP domain if we think it's not good for PHP image but that could mean t= hat 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=C2=A0
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 t= o do 2 and 3.
=C2=A0

The removal for php's dists is obviously a good first step but I would<= br> 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?

<= div>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
--0000000000001deb3c0640e6d3ba--