Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107140 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 61007 invoked from network); 16 Sep 2019 09:56:09 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 16 Sep 2019 09:56:09 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id EA4D92C0466 for ; Mon, 16 Sep 2019 00:32:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: No Received: from mail-ua1-x942.google.com (mail-ua1-x942.google.com [IPv6:2607:f8b0:4864:20::942]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Mon, 16 Sep 2019 00:32:59 -0700 (PDT) Received: by mail-ua1-x942.google.com with SMTP id k24so1743590uag.10 for ; Mon, 16 Sep 2019 00:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0D7hiIf1XfamZnw3Jmy+M4XU/9ksDOWXOpQl9QYfoUM=; b=ZX/3h71Jkfwz+s3m+Rb8yVBu0onVhAPY7WTxhEXlwcta/WN+ueQXs0llnc+O3H90ue QmsMmjxWC+tDvRHvbRi1TlqB8kyB/wnXtnoZ6zlyeBCNQWP3PVZq3AisKGNCA+fiaHhO gbc4tA0g5DsFi20kPAHevc2BllP3H3vFLH07VPeUhQNwA5RTxw9rQ6ZEK7GpWxnc+jLK woB5IqALNwtStz5o62RUvnJkNQPDi5yx5BQzegPWPGkjL/zMix3VbhTzH2V8MStsh0R8 rnlJo1SSwTyAmZtB6PYHUtLTJfutIu+JxQjn+zrvGiTiSpvN1wQHxh/mqCmDYE6q8Po2 qr7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0D7hiIf1XfamZnw3Jmy+M4XU/9ksDOWXOpQl9QYfoUM=; b=IVBPrz3fcyWPNtF59FR6SBNgj0QgUNaR5NaDV9lgDI9l8xcvrQjHhtR4bQ3gvd8to5 x8UCPHmuiN1mGkooYB6WrDGLkAw7eu9rI+unKXikjJ5/FwJ6eHEKyb9cG/m/L2vHbz56 vmUUbrsCfKTsxgPsQ2bSsPXsAFnsy04RsPac9kv0klg1j81GAhwBjgV6JRgnqXmHUrtk GcSZgpaaQ6g7D/EvreWHuJrd0kZ3Hj+rZcYMqJF0kWJruLJs29KAhg5f9HIQiYkoBMrf qy8f2eq3QrecdViuRbgXnF2MdjY8ftolG12NV+dC47K0VNmBzva4p4Lc4U5XEpz2a1Bz jr3w== X-Gm-Message-State: APjAAAXfaXaQuCQeJgd3lweL8v46krCbhWfn06bMbnLA7vSlSi66YQiW rEAvqTBQCUmIS9VKbUchC6S74MU/ja5DT+rF2FDNsxE4 X-Google-Smtp-Source: APXvYqzY9wY690Tb2JgudSqw3aEGzmn5DI4/L7od9j3KjjxBQgTcghfrZOEzzJiUpQ4RBGA4VTHBseOs1LNREKc0f+w= X-Received: by 2002:a9f:20a6:: with SMTP id 35mr1690535uaa.140.1568619178644; Mon, 16 Sep 2019 00:32:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 16 Sep 2019 09:32:47 +0200 Message-ID: To: Kalle Sommer Nielsen Cc: PHP internals , Rasmus Content-Type: multipart/alternative; boundary="000000000000ee5a070592a69cb4" X-Envelope-From: Subject: Re: [PHP-DEV] Defining the PHP Group From: krakjoe@gmail.com (Joe Watkins) --000000000000ee5a070592a69cb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Morning internals, I've got some good feedback here, my suggested words were indeed rather loose. I'd like it if we could stop saying the RFC process can't be used for one thing or another, it's patently false. The RFC process introduced itself, amends itself, is used for deprecation, addition, and removal. To say it's not suitable for these things is a total nonsense, we already use it for these things. I think maybe my use of the word "commit" was misunderstood. It is the case that a positive result means we are in some sense committed to merging the change (when a patch becomes available as in the case of null coalesce assign). I went to the effort of mentioning the specific case where an implementation is not suitable. Obviously other cases may arise where the decision is reversed by a follow up RFC, I thought this possibility was implicit. A note on the group issue: When I said it's not well defined, I didn't mean we don't have a list of names, quite the opposite, we have a list of names that are mostly unconnected to the project today. What we don't have is a definition of the role of the Group, specifically one that fits the project as it is today. This undeniably causes confusion and a certain amount of friction, both during interactions between internals members and in the wider community. Thanks for all the input, I'll give this some more thought ... Cheers Joe On Mon, 16 Sep 2019 at 05:36, Kalle Sommer Nielsen wrote: > Hi Joe > > Den s=C3=B8n. 15. sep. 2019 kl. 08.48 skrev Joe Watkins = : > > > > Morning internals, > > > > There is confusion among the community, and contained in the documented > > history of PHP on the wider internet. > > > > The Wikipedia states that PHP is developed by the PHP Group, in saying > this > > it is (must be) referring to internals as a whole, but our own > > documentation names members of the group - who aren't even around mostl= y. > > > > I think we need to clarify what exactly is the purpose of the PHP Group > > today, does anyone want to attempt to do that ? > > This is speculation/my interpretation, so take this with a grain of > salt; I think The PHP Group was the project governance back in the > day, but with PHP's ever so vastness and expansion, new developers > come in, old developers go all the time, I don't think this ever got > to be what it was meant to be. Now a days it mostly seems to serve as > a legacy of the past. > > Given the recent clarification from Rasmus, I do not think the name > has any meaning anymore besides being a fancy name that holds the > copyright, whereas the copyright probably should be updated to be: > "Copyright (C) The PHP Project", on the PHP.net website, license et > al. Besides this I cannot think of a place where I have seen a > definition of "The PHP Group" or seen it active besides its recent > mention of being an "authoritative" power (which clearly is not the > case as there is no legal ramification to hold this statement true). > > (I picked "The PHP Project" over "The PHP Development Team" which is > also commonly used to include everyone who contributes time and > resources to PHP). > > > Whatever it's purpose, if it has one, we need to make clear at this tim= e > > that there are no vetos: As Rasmus clarified, PHP is driven by the peop= le > > who write PHP: No member of any group or company, historical or > otherwise, > > has any veto powers, they cannot, and they must not behave as if they d= o. > > > > I would like to update the introduction to the Voting RFC: > > > > The development of PHP is community driven by the RFC process described > in > > this document. Anyone may initiate an RFC for any subject. At the end o= f > > the RFC process a vote is held among PHP developers to determine if the > > proposal is to be accepted. > > > > Should a proposal be accepted, the developers of PHP are committed to > > making the change. > > > > In some circumstances, merging an implementation into the source code o= f > > PHP may be delayed because of shortcomings in that implementation. In > these > > cases, resolution of these shortcomings is the responsibility of the > > proposer. > > > > Should a proposal be accepted without an implementation, it is the > > responsibility of the proposer to provide one. > > > > Does anyone object to any of those words ? > > > > Do we need to vote on changing the introduction (I'm happy to start an > rfc > > for this, if necessary) ? > > I got no objection to adding it, but perhaps an RFC should be more in > the direction of a "Mission statement" of sorts, stating what the > project is, what our goals are, who steers the direction etc. This > could be a decent start to sorting out the strings. > > > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net > --000000000000ee5a070592a69cb4--