Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:130317 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 580B71A00BC for ; Sun, 15 Mar 2026 01:45:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1773539138; bh=2mVT84Vx0q6VCFb6IZ2KfH4y1jocchQP/VNWAAEi7bo=; h=References:In-Reply-To:From:Date:Subject:Cc:From; b=X2VW9jK3379t8vFW35J3PoeZLPr8Zp+H34Bq/ObgZVLRnSOjS9wc2Uo63bz1EgxDv PL+Zoj5PzoO0gssd5jArxvNLzEuptaJab/Eweel8F5si/jFkcZKriz1ejeJkgBQVy7 o50ubeaOemxib0pfJ1zpzcd0E9mCgRvlxeQrhJlHtsIPXuq8VS+m/fK6Qf+ZekelVF 68+Q1FqkAsQVasWFEE4A21VP4+aM0ZfsMQgeXhsBplJhL8CgoGdLpW7Zu2IK6VvOi6 DB6/18ntyOwBxeeNSKaKnnNElTxxsn7iLaOY/MZeudZfq+kyY/R3HaQMiiwB4L+/U+ RIQ/CKIatXtJw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id AB7001801EA for ; Sun, 15 Mar 2026 01:45:37 +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=ARC_SIGNED,ARC_VALID,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-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 01:45:37 +0000 (UTC) Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-439fe4985efso3074866f8f.3 for ; Sat, 14 Mar 2026 18:45:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773539131; cv=none; d=google.com; s=arc-20240605; b=Nvcdt7tWlUasSHlfg0tWQe8Hsf3mTGzRSkmn5BvKSlmDDD4o9gf769xfxYA6ex5TwQ ryKm/fOYLMEZRsekOQL13ArWmits6LZiRYfEUQ4mhsjVcZqNMTlQf8d76BLrUiArYKx/ vjodDdipAhdPWmMxLOncpd0w3C33V3zrBIbJfNtA4R5iRFYhs8S3i1oTuUlvvgh8YEob YzXLuxq9aXZvN3Q3i3kVpPLB/g7K2F4D8I+HlLeC2DVuOAGshufQIck7ytc6Zu1NAJ36 dY9Tm3xqSgARIOvplgMOgUPRkloQNaIc2NpioGwYVin4M+2aPxerLbrGer4MiiW4nxvi VS8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=2mVT84Vx0q6VCFb6IZ2KfH4y1jocchQP/VNWAAEi7bo=; fh=/qcgIyK87fsdGyLS7f5yQJtoVtoRPmzlqAKZQD8bEVQ=; b=dBxqQ2OjXrBkvY4oW4825E/188iSOUbG0UbO4C7FQU5WxhfsJdRL2WFhlZkVkKVApB O2RY4jzMeVk5mQXrFxlDzKw6hCD6ODUIcLA710JnpNEylqsQkzHodioMsZGzb7BB+Qzd kcUnXuNuSv4y3m2BdmRKqXoJNaoNWVa1lGz+A3zPwlGn/ir2nfE70G9HOEK2u60cwa9a tES6gta2OyH4wxZqv++t2PCt0gjF7jCosnhqPldDTspPCUEUepkb+QUGcidhRJQUfaaP B6frJ9tk7dX0yghgJbTOzKAMpoM3hfsRMLLQbMt9R+M/G1tX3OIf0g2SA7QJPqyL70tK gD4Q==; darn=lists.php.net ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773539131; x=1774143931; darn=lists.php.net; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=2mVT84Vx0q6VCFb6IZ2KfH4y1jocchQP/VNWAAEi7bo=; b=A9dY7hbTpk1Z0VUvCmBXQtrNTdL0qH1SXu5TUkp8y7UjOpEABYHWqVv6xbBIK/j8m0 WtlmWXWEphVw/avk+ALxIQFKYhdI7G12HXAA+LR2jPFjl7OUnBz0QrdbWz6g6v/15SEV cK3NWJo5k9D9bMSCpWM9mJUU1Dqh54OL2jpsHrgLbXkFCpObyfHZ6UmsRIoegIcqchsS Eb6KXlbnnqePOUVCxOaU5r7ghUE+Z9Tc8Jj2URZ9LqK1U6zkqWQVmCGFPxwTh5l0UxW6 Qnh5Z3obEgWjw5WzzOGffWMQEFw9hF4bU/pcR9a6M5ipnD19Enko15P/8sYaX6Pu2O9c mXxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773539131; x=1774143931; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2mVT84Vx0q6VCFb6IZ2KfH4y1jocchQP/VNWAAEi7bo=; b=PlTiORnGvRG57iFwAb5fkkBBORvDJnZ168uHDjAqudO9EIknJrEj8Wt1Eytn+m2bcL yAihkLptYMV/JzPzdaRX0xQ0arl3/PwdfuCMMXTj6/dcWB6FRByFj0GOLqKxss58i536 LbK1zb+SprSwlfviBVHTMWySjivBSu8TEPgvCxFm7coGbaK8McUrs6HqSkgf3ran6+w1 taj4ybruCg4exSWupDx+CRNqBUae2vR5AitzOPgwqIjZ/cNg5+KARZZndA6G6cgWhlI3 A+l7wILXxWc5Fn0DzL4L3cqJf5xJ+NBkUqsXHhGsIBf+Iy/goW29WxqBV/csxtbnz3cB bAxw== X-Gm-Message-State: AOJu0Yyf3Ca0/ix7iZRUzQzL7qkiH34iHAgPLrYtpc2y/apbayO6weHc WKNcifLsq00Oay6p4ke3rboIb87aAGyL4ZDvSKvuHvlzkxOxdBs/Fwizw09KQ2aAODIrTA+E6kY yj4/unlcSAoETfs6FyMZ5qh9qHvIbGDqLRA== X-Gm-Gg: ATEYQzxxaEEJtKKFEodh6tIWgi6YrILZF7F/i6lekrsARvF3bJtQQAteSodAho57daX nlfo8sIcqbXuJ5SayvZJhVTPtOkPSfdvX2grG4h722vfPEXTC+3NcVd4lg6LZuIs5tHoyVWV858 od8zLUvFXhUx4id24y5T1evYPfZdeN00p+m7TooVjy08Slw91t7Yr1DZti3pSafh0Am3iRTUn4z nRAvh+y2eYDFKvTjGSymOt1aCOP3QNExAs2sPDQ9er6U6Y059KYu2DKETXAcveYdULeaFxWrdar kYMFRE8d9LD2BQxYtBtA5T9I20Lu1WpanR8726DntRwti4E= X-Received: by 2002:a05:6000:2012:b0:439:ddc0:4bf0 with SMTP id ffacd0b85a97d-43a04dc0c02mr14924918f8f.44.1773539130884; Sat, 14 Mar 2026 18:45:30 -0700 (PDT) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com> In-Reply-To: Date: Sun, 15 Mar 2026 02:45:19 +0100 X-Gm-Features: AaiRm52sz258lAGu51MQib3q5AhP7LxL15wc4S08k3VHw2Wkpz_ijmKP01ABBsk Message-ID: Subject: Re: [PHP-DEV] [RFC] php-community: a faster-moving, community-driven PHP. Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000e448aa064d0641d2" From: daniil.gentili@gmail.com (Daniil Gentili) --000000000000e448aa064d0641d2 Content-Type: text/plain; charset="UTF-8" > > > > > > Submitting for discussion the php-community RFC, for a faster-moving, > community-driven PHP: https://wiki.php.net/rfc/php-community > > I understand and appreciate your desire to accelerate the development > speed of PHP. However, this proposal would put a completely > unrealistic burden on php-src maintainers. > > By design, it would become very easy to add new features to the > community branch. However, code isn't merged and forgotten; it > requires continued maintenance. Features interact, bugs need to be > fixed, code will diverge from release branches and require conflict > resolution, development of features through PRs would still require > reviews by maintainers, etc. The additional effort to keep all of this > working correctly for underspecified and questionable features would > be immense. > As mentioned in the RFC and earlier in the thread, the burden of maintaining feature extensions will lay exclusively on the owners of the community RFCs, and any other maintainers appointed by them. Features and bug fixes for feature extensions will NOT be a responsibility of php-src maintainers. This also includes reviews on feature extension code, which will be a exclusive responsibility of the owners of said features. In other words, feature extensions are "guests" allowed into the php-community branch, and are developed and maintained exclusively by their owners just as if they were a standalone extension. Of course, a more detailed review on behalf of php-src maintainers is still preferable for the initial addition PR, but it is not required (even if obviously still allowed) for subsequent PRs. > There's no real veto for php-src maintainers, a single internals > member can overrule the "veto" mentioned in the RFC. No, that is not correct, a single internals member cannot overrule a veto made by all remaining internals members. Only 50%+1 internals members put together can overrule a veto made by the remaining half. If a problematic > feature is accepted, it must be supported for at least 6 months, > By the feature owner, not php-src maintainers (again, like with Linux). further burden falls on php-src maintainers to propose the removal of > the problematic feature, and it might not even be removed unless: > > > Adoption is negligible, as evidenced by Packagist statistics. > To be honest, this is not all too different from the current state of PHP: there is a large amount of extension code in core which are only there because it was added a long time ago to cover a specific usecase, and is still there even if technology has moved on and that feature is no longer in use by the *majority* of the PHP userbase (thinking about legacy db drivers). In php-community, actual, real adoption statistics will be available through packagist, making removal actually a lot easier. > I think this development model works much better with authoritative > working groups or a benevolent dictator, along with a coherent > roadmap. And crucially, failed ideas would be removed before this > community edition becomes a cemetery of failed ideas. > I partially agree, and partially disagree. Go indeed does have a few benevolent dictators that get the final words in case the various committees cannot find an agreement: this has worked out *mostly* well for them, but unlike processes, a benevolent dictator is not something that can be easily copied. I personally cannot think of a single person that can be entrusted with the role of a benevolent dictator for PHP. On the contrary, I believe that the current status quo of PHP is "a bunch of dictators with largely varying opinions" is actually a good thing, because internals members fight it out in full transparency, in a public mailing list, presenting a variety of viewpoints and arguments. The only missing thing, which is the main reason why I made this RFC, is real adoption data and feedback from the community that can be used to empower or defeat viewpoints during the public internals argument. The definition of "failed ideas" should not be up to any single internals member to decide, it should be up to the actual users, who actually get to use the language every day. Regards, Daniil Gentili. > > --000000000000e448aa064d0641d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

>
> Submitting for discussion the php-community RFC, for a faster-moving, = community-driven PHP: https://wiki.php.net/rfc/php-= community

I understand and appreciate your desire to accelerate the development
speed of PHP. However, this proposal would put a completely
unrealistic burden on php-src maintainers.

By design, it would become very easy to add new features to the
community branch. However, code isn't merged and forgotten; it
requires continued maintenance. Features interact, bugs need to be
fixed, code will diverge from release branches and require conflict
resolution, development of features through PRs would still require
reviews by maintainers, etc. The additional effort to keep all of this
working correctly for underspecified and questionable features would
be immense.


As mentioned in the RFC and earlier in the= thread, the burden of maintaining feature extensions will lay exclusively = on the owners of the community RFCs, and any other maintainers appointed by= them.

Features and bug = fixes for feature extensions will NOT be a responsibility of php-src mainta= iners.
This also includes reviews on feature extensi= on code, which will be a exclusive responsibility of the owners of said fea= tures.

In other words, f= eature extensions are "guests" allowed into the php-community bra= nch, and are developed and maintained exclusively by their owners just as i= f they were a standalone extension.

Of course, a more detailed review on behalf of php-src maintain= ers is still preferable for the initial addition PR, but it is not required= (even if obviously still allowed) for subsequent PRs.



There's no real veto for php-src maintainers, a single internals
member can overrule the "veto" mentioned in the RFC.
=

No, that is not correct= , a single internals member cannot overrule a veto made by all remaining in= ternals members.

Only 50= %+1 internals members put together can overrule a veto made by the remainin= g half.

If a problemati= c
feature is accepted, it must be supported for at least 6 months,

By the feature ow= ner, not php-src maintainers (again, like with Linux).

=
further burden falls on php-src maintainers to propose the removal of
the problematic feature, and it might not even be removed unless:

> Adoption is negligible, as evidenced by Packagist statistics.

To be honest, t= his is not all too different from the current state of PHP: there is a larg= e amount of extension code in core which are only there because it was adde= d a long time ago to cover a specific usecase, and is still there even if t= echnology has moved on and that feature is no longer in use by the *majorit= y* of the PHP userbase (thinking about legacy db drivers).

In php-community, actual, real adoption = statistics will be available through packagist, making removal actually a l= ot easier.


I think this development model works much better with authoritative
working groups or a benevolent dictator, along with a coherent
roadmap. And crucially, failed ideas would be removed before this
community edition becomes a cemetery of failed ideas.

I partially agree, and parti= ally disagree.

Go indeed= does have a few benevolent dictators that get the final words in case the = various committees cannot find an agreement: this has worked out *mostly* w= ell for them, but unlike processes, a benevolent dictator is not something = that can be easily copied.

I personally cannot think of a single person that can be entrusted with = the role of a benevolent dictator for PHP.

On the contrary, I believe that the current status quo o= f PHP is "a bunch of dictators with largely varying opinions" is = actually a good thing, because internals members fight it out in full trans= parency, in a public mailing list, presenting a variety of viewpoints and a= rguments.

The only missi= ng thing, which is the main reason why I made this RFC, is real adoption da= ta and feedback from the community that can be used to empower or defeat vi= ewpoints during the public internals argument.

<= /div>
The definition of "failed ideas" should no= t be up to any single internals member to decide, it should be up to the ac= tual users, who actually get to use the language every day.


Regards,<= /div>
Daniil Gentili.

--000000000000e448aa064d0641d2--