Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120168 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 65698 invoked from network); 1 May 2023 11:32:03 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 May 2023 11:32:03 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9B8471804AA for ; Mon, 1 May 2023 04:32:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 1 May 2023 04:32:01 -0700 (PDT) Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-50bc25f0c7dso2736074a12.3 for ; Mon, 01 May 2023 04:32:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682940720; x=1685532720; 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=iSiIjIYhT6UrV+1TvPnWnzCfLzdbXOdtaqVCbonjNKs=; b=c9xR6T9+Y8xqykftOLTYir0vXTyDD7w6WEYbSl5iVZSmwbQX9WVkJN5cFNjs9g7v/P wBv2J00a/Ya7Z35I6UJA8GTtivyf4cXuHHHFo54bYMpu0z/iByNtpsbJXpBpFpOfuTBy VXTXqYOCUF7KB6O/ZeXGkthMcwLJCShjQi+K14kawGE7Ju0QdnKtV4FcKi/UJQsWvoW3 kAl0+1D4ps3GZMrLDefVls/mCqUF4+yAOTQsLn2husFvYEi1EOH60DcKbSpapZBXxtyp pIODsR5TvnKvfDMoSLjtHJqGdc/rM14df1PWzJe5uLSIyD9jHXaSzDesSTqiOLTreCjX Ul9A== X-Gm-Message-State: AC+VfDwrpzx0uKxKffqZJADiNl0ymyHs4xWEXs4KTgz8zQ2/gr2fI5tC zyaecWer7DpGdIPWb2dTSUmWy9BZO+ve7mglF3k= X-Google-Smtp-Source: ACHHUZ7reEyIqaE/vCr6qnkVtqHDXXN0UDbx2O+Gdt1MfNiL4ICXKQW/Twg8Mpmkow85qq002JU0bcOjXhjtm25ZFFU= X-Received: by 2002:aa7:d302:0:b0:506:9805:7b56 with SMTP id p2-20020aa7d302000000b0050698057b56mr6300326edq.32.1682940720238; Mon, 01 May 2023 04:32:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 1 May 2023 12:31:48 +0100 Message-ID: To: =?UTF-8?Q?Pedro_Magalh=C3=A3es?= Cc: PHP internals list Content-Type: multipart/alternative; boundary="000000000000ced20a05faa02b11" Subject: Re: [PHP-DEV] [VOTE] PHP Technical Committee From: bukka@php.net (Jakub Zelenka) --000000000000ced20a05faa02b11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the feedback and explaining your no vote. That's really appreciated and would be great if other no voters could do so as well. On Sun, Apr 30, 2023 at 10:36=E2=80=AFPM Pedro Magalh=C3=A3es wrote: > On Fri, Apr 28, 2023 at 11:00=E2=80=AFAM Jakub Zelenka wr= ote: > >> Hi, >> >> The vote is now open for the RFC about introduction of the PHP Technical >> Committee: >> >> https://wiki.php.net/rfc/php_technical_committee >> >> Regards >> >> Jakub >> > > Hi Jakob. > > Sorry for not participating in the discussion phase but I would like to > give my explanation on why I voted No. > You made a good job in distinguishing the user-facing from the technical > changes to say what can and can't be decided by the TC, but the first can= 't > live with the second. > Well obviously you cannot have user facing change without implementation. But you can have a general idea accepted without the implementation (or with just some base implementation showing that it might work). This is actually how the spec based languages work. Firstly the spec is created and then it is implemented. I know PHP is not a spec based language but there is no requirement for the implementation in the current RFC process. It is all just about the proposal. Of course there is a better chance to get it accepted with a good implementation done but it is not a requirement. Then, it allows the TC to have conversations and vote in private in matters > that until today have always been public. Of course developers are allowe= d > to talk to each other wherever they want, but what matters is said in > public. > "unless the provided implementation would result in introduction of new > bugs, side effects not mentioned in the RFC, significant performance > penalties not mentioned in RFC, or if there is an equivalent implementati= on > in progress that the TC finds more appropriate." is ample enough that it > can allow anything to be rejected. > > So the fact that the RFC passes does not necessarily mean that the implementation will be merged. It will most likely won't get merged if it introduces some security issues or problems that were not envisioned during the RFC process. This is just to make that decision about quality of the implementation more formal and have some process to decide it. > Overall, the idea of having a group of people that developers can ask for > some guidance from is great, but that group shouldn't have any extra righ= ts > to block anything whatsoever. > > To demonstrate good faith and unequivocally show that this is not an > attempt at a power grab, it would be a nice gesture for the authors of th= e > RFC to include their withdrawal from ever holding a seat in the technical > council in the text of the RFC itself. > Well this is a collaboration effort which you can see in the linked PR. Being an author does not really mean anything here. The proposal is to have 5 people in the committee that need to be already a core developers and they react only to issues raised by other core developers. So I can't really imagine how this could significantly change things and be a "power grab". It is purely about deciding the conflicts between people that have got already powers to potentially block things. It is basically just about finding an agreement between core developers. I have just done some analysis of the current RFC process in https://news-web.php.net/php.internals/120167 where you can hopefully see that this does not take any powers from the current RFC process. Cheers Jakub --000000000000ced20a05faa02b11--