Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119671 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 11548 invoked from network); 6 Mar 2023 05:20:47 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 Mar 2023 05:20:47 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5551F180511 for ; Sun, 5 Mar 2023 21:20:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,SPF_HELO_NONE, SPF_PASS,T_PDS_PRO_TLD,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 138.201.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from swift.blarg.de (swift.blarg.de [138.201.185.127]) by php-smtp4.php.net (Postfix) with ESMTP for ; Sun, 5 Mar 2023 21:20:45 -0800 (PST) Received: from swift.blarg.de (swift.blarg.de [IPv6:2a01:4f8:c17:52a8::2]) (Authenticated sender: max) by swift.blarg.de (Postfix) with ESMTPSA id 86B9940ECD; Mon, 6 Mar 2023 06:20:43 +0100 (CET) Date: Mon, 6 Mar 2023 06:20:42 +0100 To: Juris Evertovskis Cc: 'PHP Internals' Message-ID: References: <014201d94fbc$547b6840$fd7238c0$@glaive.pro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <014201d94fbc$547b6840$fd7238c0$@glaive.pro> Subject: Re: [PHP-DEV] RFC: code optimizations From: max+php@blarg.de (Max Kellermann) On 2023/03/06 00:43, Juris Evertovskis wrote: > The current amount of secondary votes makes it feel daunting. I would > suspect not all voters will think thoroughly about each of the questions. > I suggest that most of these questions could be agreed upon in discussions > before the vote. Casting a vote seems like the canonical way to get a decision, but I agree that the number of secondary votes makes this RFC somewhat unwieldy, that was my thought as well. If the discussion leads to an agreement, of course I'm open to removing affected secondary votes. For now, let's consider the list of secondary votes like a discussion agenda. > Maybe the RFC could propose a certain wording of the guidelines? The > community could then agree on most details via a discussion. Yes, that should certainly be amended, but I did not yet suggest a wording, because that would be the result of the pre-vote discussion. I'm not even sure if this RFC isn't ill-advised - it is based on my (undisputed) understanding that code optimizations are not covered by what is allowed to be done without a RFC (after somebody pointed out that merging my work violated community guidelines), yet every day other people's code optimizations are accepted. Not just that - at least once, after my work was reverted, somebody else resubmitted the exact same change and it got accepted. I'm confused, and I seek clarification. Max