Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:130330 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 E7EC41A00BC for ; Sun, 15 Mar 2026 12:20:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1773577242; bh=OoD66tODv3EEDHiIPPiOTpo249kihbDFOVg9QflUujU=; h=From:Subject:Date:In-Reply-To:Cc:References:From; b=Gx5Jra/blytnRlF9OCJ6TPqI7cUxqp3zECQEAqY/OJmDyvuysN045Uwua5WIkXU41 lJswgz38xNw6hZRd3/fAkSgtgJyd82e9KP+wXm8QQ8J8JHHVNraSWYepx+nvJcywdn /Z4A9J+9N3XAopGJBpGlDOKPKMuRHiKnnqkTAaCR4nxeX64sbcKbkiLjaY9HGxjyZc 09/Xghda4y0d/0KX+Y2KvrNqmKiRpCd5xsiFwU+aC8t/FwaZxuDzj+u2LvzFUwAJnO 459Y3nWujNz93RV+2mxJcWTlQxaGXqVvm9b1kQS6kvHrSgow6nF4BrS2fqDGND8qiG MeGFDCII6nlOw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 60BFB18058B for ; Sun, 15 Mar 2026 12:20:41 +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.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,MISSING_HEADERS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 ; Sun, 15 Mar 2026 12:20:40 +0000 (UTC) Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-48538c5956bso33978195e9.0 for ; Sun, 15 Mar 2026 05:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773577234; x=1774182034; darn=lists.php.net; h=message-id:references:cc:in-reply-to:date:subject:mime-version:from :from:to:cc:subject:date:message-id:reply-to; bh=nTFeQK+lFJ0xbhxpibFyPJrzE5XkI0XzIY2+2QM0QY8=; b=RTCC2rozSwwdUNtbyZ6Hk9cUPn270JlFxb6DJ5AMcfVfJkt/AbJ+FPXvDuTahXS96F Fml25GIlhiZCh7yTRLH3MA74tcepu+0PIQShUSAlxOBUdAujVrEIuysleZYcS+1PGRfj 60Af6A2otNTiQU5lgVBW0QbNqAchqLeVBYCQAaIkwL4t6y765fz7Qpm7AZt3Gg0KjaMC x0MQaQTVwvNWV7WfZIYvDfTttTxtLnNRNocHJLHD9CVfB4FJjYQFwmjghX0Bh+bBQ1t4 ktqYntF8U4Ju8U549HcVWIyD6xcwWu0mRUQSxlh55ThQX+u+qBJ5yyOC5gUAzpfH+IQA 8ZXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773577234; x=1774182034; h=message-id:references:cc:in-reply-to:date:subject:mime-version:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nTFeQK+lFJ0xbhxpibFyPJrzE5XkI0XzIY2+2QM0QY8=; b=BxxL5THQeduUtLBNGuHucvVs/cfRJi6c9nZn5RmmhpwPPNMlulQHUwFjkH+kw7BqiO 2Cev7Nws0Ms1YKZbEx5Vi8tKyd1KdIUV8KI2bKGE9VY5h1Iv/xMBE6QIi9UI7XRytN/Y 2KICz/pokqAtNJsSOjvC4FBNNq0xJfR20agmdoQKvxyzDvn2i7FalHfmURisj20v9NIK HuVrNaC9QcOmvV7gDKWiYsLYpd4snNJsb36mKT3RQLoc8atarq3ZoGD55S2IrF7nKmHc obxuN5lomiJDFPRhu3NqcU9wP4UBLJBDAxqTznAv/6xfPp2yGINrEsXpX3JAiHS9KPwu NjpQ== X-Gm-Message-State: AOJu0Ywmw8tm4PzTxFLMURkQr1pXh+bN8ohQ5MqjOQNQDLviqRC24q5f QFUsiukyxO9hJECAOlaPeWHpd/1dZWBM5aJFCLAEZpe35du5o89yg8O2hrMltQ== X-Gm-Gg: ATEYQzygWwBF0Fh1socjZGGmHzwNODMCI2XKnRPdeKPxRLJdCuqrOxcWebPd9hPZBYq hz4vVqGeIl09gxtHWCsmo5+fPjuE97BG7EErESqp3OYI3KkX5hvXtst5y9/7fvNhTxoNWg1p6D/ dzK6yuRfGg50X8XGTvfAUUcvoXHSzm2xgKoNqzMt+E85nzr7H9FqqkmcyzU8kfhyIsteddxXwpS yOPWbZtu5CzTHtiw2uxQPrqjv+PPMHbdwjVwpDgDpv24db55bmeofZq3F8QcycVJWGYvP2EmkGN +DNrU3n4zh1I8Lyw3G+tv+uJbicH3ZV6ALPy9MSjrbwbFBikO9rMZE2OnJjkynOs0zCnxEiAL84 besuTcGYeHQz7bR2ILqAPoK8ekPG47+wUxvgKXM0YXeFCfiMggqjxKGu2KUHuKcXPnP+LWdu7FJ uImcb6H9gDGrDtO9BM3mAFpKr15t/h3FuT5xhEg4HHlIR7XMl80/i1GpiQDezeeTPHUWISd/3mN rcQc8/Od1eVgldMwqA+9t1SX5SPfTL04U3WQJ2NQqoI/S0= X-Received: by 2002:a05:600c:8b18:b0:479:13e9:3d64 with SMTP id 5b1f17b1804b1-48555b47c4dmr149661585e9.15.1773577233349; Sun, 15 Mar 2026 05:20:33 -0700 (PDT) Received: from smtpclient.apple (luna-7251fd885a1220d60000f.net.as198747.daniil.it. [2a0e:97c0:38f:0:6d02:21a5:88df:1527]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48557c66583sm70562725e9.21.2026.03.15.05.20.32 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Mar 2026 05:20:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7CBA8A59-B0B5-4DDF-BB90-952CE0EDCE87" Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\)) Subject: Re: [PHP-DEV] [RFC] php-community: a faster-moving, community-driven PHP. Date: Sun, 15 Mar 2026 13:20:22 +0100 In-Reply-To: <299760A8-5C8A-41AD-B2EB-986079D41A47@rwec.co.uk> Cc: internals@lists.php.net References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com> <299760A8-5C8A-41AD-B2EB-986079D41A47@rwec.co.uk> Message-ID: X-Mailer: Apple Mail (2.3864.400.21) From: daniil.gentili@gmail.com (Daniil Gentili) --Apple-Mail=_7CBA8A59-B0B5-4DDF-BB90-952CE0EDCE87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 >=20 >> For the first time, official binaries and packages will be provided = for all major Linux distros for php-community releases on php.net >=20 > Who is going to create and maintain these packages? Who decides which = distros, which versions, etc? Like sandboxing, this could fill an RFC on = its own. >=20 Initially me as the author of the RFC, then php-src maintainers. Splitting up this RFC into sub-RFCs is not an issue to me, but I would = prefer to get a general positive consensus before spending more time on = actual implementation. >=20 >> Multiple versions of the same feature may be offered at the same time = in a single php-community release >=20 > How will this work, code-wise? Are these versions actually separate = implementations side by side, or limited to changes that can be = represented with feature flags? >=20 > What is the minimum lifetime and lifecycle of these versions? Can a = version be retired early if it has an unsolvable stability or security = issue?=20 >=20 Clarified that this was mainly meant for removal/deprecation feature = extensions. The exact lifecycle is explicitly not defined to allow for more = flexibility, but it can have emergency yanks for security issues, just = like for all extensions. >=20 >> internals members through GitHub =F0=9F=91=8D =3D Accept, =F0=9F=91=8E = =3D Reject, =F0=9F=91=80 =3D Abstain reactions on the issue using their = GitHub accounts, >=20 > I don't think we have any suitable definition of "internals members" = that can apply here. Do you mean people with commit access to the = php-src repo? Or are you hoping to cross-check GitHub users against = main.php.net accounts (as used by the current voting widget) somehow? >=20 By internals members I mean users with current voting rights, who will = provide their GitHub nicknames. >=20 >> A feature is eligible for removal only if both of the following = conditions are met: >> - It has no active maintainer listed in the accepted community RFC = design document. >> - Adoption is negligible, as evidenced by Packagist statistics. >=20 > This feels incompatible with the rest of the process. If features are = easy to propose, release, and iterate, it should be just as easy to mark = them abandoned or obsolete. Otherwise, an interesting but flawed feature = has to be maintained forever even if its author loses interest - and who = is going to do that maintenance? >=20 > If the intention of these features is to be experimental, perhaps = every feature version could have a fixed lifetime. Users know that they = can't rely on it long-term, but if it's popular it will hopefully make = it into a stable release of PHP. >=20 The point here is that users MUST be able to rely on feature extensions, = including in the long-term: this is the reason for the stringent removal = requirements. >=20 >> php-community will always be based on the latest stable PHP release >=20 > Who will be responsible for merging changes made to "feature = extensions" back to master, and stabilising the first community release = after a new stable release? >=20 >=20 The feature owners handle all changes to feature extensions. Normal PHP RMs handle merging stable PHP into the community branch. >> Community releases are =E2=80=9Chandled=E2=80=9D by the same release = managers of the latest stable PHP release, however the release process = will be significantly automated, compared to the current manual release = process >=20 > Is there something that makes this automation easier for community = releases than regular ones? Or is automaton of the existing process = something that needs to be done before we can consider this RFC? >=20 It can be applied to regular ones as well, but it was added mainly to = work around the fact that normal PHP already has third-party distro = packaging, while php-community will not, unless it is provided from the = start by php.net directly. >=20 >> Wait for the CI status of the new branch to become green >=20 > If there are failing tests in a particular feature when it's time to = tag a community release, what happens? Does the release get delayed = until the maintainer of that feature fixes it? >=20 Feature maintainers cannot merge a failing PR, just like with all other = php-src PRs. >=20 >> php-community will live on a new community branch of php-src >=20 > Who will be responsible for the stability of this branch? This is = really important, because you're targeting this concept at shared hosts, = who want to know the software they're running is stable and secure. >=20 The feature authors, backed by the judgement of internals members and = php-src maintainers. > Why will somebody trust this branch containing a bunch of = separately-maintained feature extensions any more than they would trust = a repository of PIE extensions? If anything, it is far *more* dangerous, = because the features aren't limited to the normal extension API. Sandboxing plays the single most important rule in building trust. >> Note: the first community RFC may indeed be the one regarding the = choice of appropriate sandbox keys. >=20 > By definition, the sandbox mechanism needs to exist outside of the = feature extension system, and be stable across community versions. As = others have said, it's basically independent of this proposal, and = should be its own RFC following the normal process. >=20 Yes, absolutely. >=20 > In other replies on this thread you've emphasised the role of feature = maintainers, but the RFC doesn't go into much detail about how that role = will work. Will it be like maintaining a PIE extension, committing code = directly, but in a directory of php-src? Or are other members of the = community expected to review their code and merge it? >=20 Clarified now, mainly it=E2=80=99s like maintaining a PIE extension = committing code directly to php-src, with *some* supervision from = php-src maintainers (mainly just a basic qualitychecks), crucially = little impact on the actual API and design (which is the main way to = reduce load on php-src maintainers). >=20 > I think this RFC is trying to do two conflicting things at once:=20 >=20 > 1) allow users to test far-reaching, experimental, changes to the = language and engine > 2) allow users to enable safe, stable, features without installing = untrusted binaries >=20 These are not conflicting things, they complement each other. > For problem 1, what we need is a way to get usable builds into the = hands of users from experimental branches of the source. If CI tooling = and release packaging can be automated enough, there's no reason to = limit it to just one "community" branch. >=20 Actually, the second php-community distro could theoretically be skipped = altogether, shipping PhpFeatures into normal PHP, which would likely = increase adoption even more. > For problem 2, we need stronger guarantees of stability, not weaker = ones: better sandboxing so people trust extensions more, perhaps; or = more feature flags within the existing release cycle. Sandboxing is expected to cover this. >=20 >=20 Regards, Daniil Gentili. --Apple-Mail=_7CBA8A59-B0B5-4DDF-BB90-952CE0EDCE87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


For the first = time, official binaries and packages will be provided for all major = Linux distros for php-community releases on = php.net

Who is going to create and maintain these = packages? Who decides which distros, which versions, etc? Like = sandboxing, this could fill an RFC on its = own.


Initially me as = the author of the RFC, then php-src maintainers.
Splitting up = this RFC into sub-RFCs is not an issue to me, but I would prefer to get = a general positive consensus before spending more time on actual = implementation.


Multiple versions = of the same feature may be offered at the same time in a single = php-community release

How will this work, code-wise? = Are these versions actually separate implementations side by side, or = limited to changes that can be represented with feature = flags?

What is the minimum lifetime and lifecycle of = these versions? Can a version be retired early if it has an unsolvable = stability or security issue? =


Clarified that this = was mainly meant for removal/deprecation feature = extensions.

The exact lifecycle is explicitly = not defined to allow for more flexibility, but it can have emergency = yanks for security issues, just like for all = extensions.



internals members = through GitHub =F0=9F=91=8D =3D Accept, =F0=9F=91=8E =3D Reject, =F0=9F=91= =80 =3D Abstain reactions on the issue using their GitHub = accounts,

I don't think we have any suitable = definition of "internals members" that can apply here. Do you mean = people with commit access to the php-src repo? Or are you hoping to = cross-check GitHub users against main.php.net accounts (as used by the = current voting widget) = somehow?


By = internals members I mean users with current voting rights, who will = provide their GitHub nicknames.


A feature is = eligible for removal only if both of the following conditions are = met:
-  It has no active maintainer listed in the accepted = community RFC design document.
-  Adoption is negligible, as = evidenced by Packagist statistics.

This feels = incompatible with the rest of the process. If features are easy to = propose, release, and iterate, it should be just as easy to mark them = abandoned or obsolete. Otherwise, an interesting but flawed feature has = to be maintained forever even if its author loses interest - and who is = going to do that maintenance?

If the intention of these features = is to be experimental, perhaps every feature version could have a fixed = lifetime. Users know that they can't rely on it long-term, but if it's = popular it will hopefully make it into a stable release of = PHP.


The point here = is that users MUST be able to rely on feature extensions, including in = the long-term: this is the reason for the stringent removal = requirements.


php-community will always be based on the latest stable = PHP release

Who will be responsible for merging = changes made to "feature extensions" back to master, and stabilising the = first community release after a new stable = release?



The = feature owners handle all changes to feature = extensions.

Normal PHP RMs handle merging = stable PHP into the community branch.

Community releases are = =E2=80=9Chandled=E2=80=9D by the same release managers of the latest = stable PHP release, however the release process will be significantly = automated, compared to the current manual release = process

Is there something that makes this = automation easier for community releases than regular ones? Or is = automaton of the existing process something that needs to be done before = we can consider this = RFC?


It can be = applied to regular ones as well, but it was added mainly to work around = the fact that normal PHP already has third-party distro packaging, while = php-community will not, unless it is provided from the start by php.net directly.


Wait for the CI = status of the new branch to become green

If there = are failing tests in a particular feature when it's time to tag a = community release, what happens? Does the release get delayed until the = maintainer of that feature fixes = it?


Feature maintainers = cannot merge a failing PR, just like with all other php-src = PRs.


php-community will live on a new community branch of = php-src

Who will be responsible for the stability of = this branch? This is really important, because you're targeting this = concept at shared hosts, who want to know the software they're running = is stable and = secure.


The feature = authors, backed by the judgement of internals members and php-src = maintainers.

Why will = somebody trust this branch containing a bunch of separately-maintained = feature extensions any more than they would trust a repository of PIE = extensions? If anything, it is far *more* dangerous, because the = features aren't limited to the normal extension = API.

Sandboxing plays the single most = important rule in building trust.


Note: the first = community RFC may indeed be the one regarding the choice of appropriate = sandbox keys.

By definition, the sandbox mechanism = needs to exist outside of the feature extension system, and be stable = across community versions. As others have said, it's basically = independent of this proposal, and should be its own RFC following the = normal process.


Yes, = absolutely.


In other = replies on this thread you've emphasised the role of feature = maintainers, but the RFC doesn't go into much detail about how that role = will work. Will it be like maintaining a PIE extension, committing code = directly, but in a directory of php-src? Or are other members of the = community expected to review their code and merge = it?


Clarified now, = mainly it=E2=80=99s like maintaining a PIE extension committing code = directly to php-src, with *some* supervision from php-src maintainers = (mainly just a basic qualitychecks), crucially little impact on the = actual API and design (which is the main way to reduce load on php-src = maintainers).


I think = this RFC is trying to do two conflicting things at once:

1) = allow users to test far-reaching, experimental, changes to the language = and engine
2) allow users to enable safe, stable, features without = installing untrusted = binaries


These are = not conflicting things, they complement each other.

For problem 1, what we need is a way to get = usable builds into the hands of users from experimental branches of the = source. If CI tooling and release packaging can be automated enough, = there's no reason to limit it to just one "community" = branch.


Actually, = the second php-community distro could theoretically be skipped = altogether, shipping PhpFeatures into normal PHP, which would likely = increase adoption even more.

For problem 2, we need stronger guarantees of = stability, not weaker ones: better sandboxing so people trust extensions = more, perhaps; or more feature flags within the existing release = cycle.

Sandboxing is = expected to cover this.




Regards,
Daniil = Gentili.

= --Apple-Mail=_7CBA8A59-B0B5-4DDF-BB90-952CE0EDCE87--