Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111500 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 14714 invoked from network); 13 Aug 2020 09:13:39 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Aug 2020 09:13:39 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E8427180533 for ; Thu, 13 Aug 2020 01:13:29 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 13 Aug 2020 01:13:29 -0700 (PDT) Received: by mail-ot1-f44.google.com with SMTP id h16so4136913oti.7 for ; Thu, 13 Aug 2020 01:13:29 -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=M1lvHlXOiCaD5lsQ1xocsdtfTvfYNTjp1pJAfZ/xPRo=; b=YU5QPubAdTWfvBYm+6T4tD4Mal2Bi3MBug2egZaoeMDHM6ouIFiU0ebvsDV3M7wW1l G4Bq7/Q+FXMLkwaU1oWB958PXhlJDKJjho1ugad8upWB5oqdBooopYU+g3RgP8iWJmyL lm2qxxhYmArAp2Tx1Rsle8phPjznzOoWAh/1abmyt/hM56q36oJY1ndomF/uurwSXCxx X23mG2Gckv6G6Zbntt92vSqFokOYtVN1xIHqm4I8V4PyKHPLkPCwxyE8FWEL3p8M2xKK ULltApukHnAS2brp0NqinLz1r8CMkIFUDZDffZinf+LqEeBN4UjuLHSmTfhu5oLubQ8B JAUw== 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=M1lvHlXOiCaD5lsQ1xocsdtfTvfYNTjp1pJAfZ/xPRo=; b=Nh6lKFGEpU1BdDlETsJU9HAkC1J43sd6FVKv/+XCxTv3Yb7UqU0XKH7o+phzTRslhP b9ieyp5VMUsuMsh5fJYGoHcXWG1FBCFYon9Efe6gvQyXFJK3YCVb5VIAYpSyNsBb5YlE sLk5nQa3HXrHQkviIUdfSt4Cdxeo6BmfFIfb+rk/FJNYfywGV1NDYFZg0bboZzvCEydn vHHg4KVJVXC5sEtafGUZ3K95idi/4xe7cXZH6qkEghLLUmgYdHYayNejTR8vGDFOrn7F 4mESgIOj9sCafu5WQeRDpgaEbmWo7JSTt8qh9txHr1g4upf++ck9ixwyBduIfKW9R2oJ H+4A== X-Gm-Message-State: AOAM5329qZb6sKj8K8GC+PqxvhrmAn224I1P/evMXdFZ+XLr1JyFP52l aA9/2lAcdQFBY0V9er791tuwqE24kIuR644g4FM= X-Google-Smtp-Source: ABdhPJxB8cAM+a8VrBfcdm8NpwpzJnBspiekOIbFVhLl09wg5PrK3YtukfFg/lxBHHsT4nBwrlcKnhDQX9meQj9v9jQ= X-Received: by 2002:a9d:5786:: with SMTP id q6mr3256162oth.258.1597306407873; Thu, 13 Aug 2020 01:13:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 13 Aug 2020 10:13:16 +0200 Message-ID: To: Theodore Brown Cc: Sara Golemon , PHP Developers Mailing List Content-Type: multipart/alternative; boundary="00000000000009f09205acbde17b" Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=) --00000000000009f09205acbde17b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Theodore, =C5=9Br., 12 sie 2020 o 18:36 Theodore Brown napis= a=C5=82(a): > On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon wrote: > > > On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown wrote: > > > > > It has just come to my attention that this RFC was rushed to vote > > > after less than the minimum two week period required after it was > > > brought up on list. Furthermore, discussion was still very active at > > > that time - I certainly didn't have a chance to respond to some of > > > the emails before voting began. > > > > > > Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the > > > vote was started this Monday at 3:41 AM, less than 12 days, 18 hours > > > after the announcement. Per the voting rules: > > > > So, 30 hours short of 2 weeks. I'm going to ascribe good intentions > > in trying to get the issue resolved in the minimal timeframe. The > > fact active discussion was ongoing makes this a questionable choice, > > but in my opinion, purely on a matter of time, quibbling over 30 hours > > is splitting hairs. Maybe compromise on adding time to the vote end > > period so that the total is greater than 4 weeks? > > > > > What should be done to prevent this rule from being violated? > > > > Vigilance. You're right to raise the concern. And let's wag a finger > > over it at least. If others agree that it's premature, we can stop > > the vote, but I'm not inclined to disrupt the process over such a > > small variance. > > On top of violating the minimum two week discussion period, I believe > this RFC also breaks the rule on resurrecting failed proposals. When > I authored the Shorter Attribute Syntax RFC, I specifically did not > include a voting option for `@:`, since this syntax was declined, > and my understanding was that a six month waiting period is required > before resurrecting rejected proposals. [1] > > But if we can vote again on `#[]` and `<<>>` after they were declined, > why can't we also vote again for `@:`? This syntax has the advantage > of being equally short as `@@` without any BC break. > > I'm really disappointed and disillusioned with how the process has > been handled for this RFC. It seems like the rules are arbitrarily > going out the window in order to keep voting until the desired result > is reached. > > What is the point of having rules if they aren't followed or enforced? > If anyone else is troubled by the precedent being set by this RFC, > please vote No on the primary vote. I'm not sure what other recourse > we have at this point. > > Sincerely, > Theodore > > [1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals You hint to the fact of shorter discussion period and the fact that you haven't got time to respond to all discussions while if you take a closer look on ML [4] that is obvious that discussion in fact began earlier and it's 3 weeks from now and to avoid insinuation you replied to it [5] 3 weeks ago as well. You blame others for breaking rules which in fact are not broken. IMO you think they're broken cause of your own interpretation. Rejected features have nothing to do with a re-vote on a syntax change at least this is how I understand this. Besides you already mentioned this argument on ML [1] so we can argue actually if a re-vote on syntax change is actually resurrecting a declined proposal since it was not a standalone proposal which got into a declined section of RFC's index [2] and yet you did it again! You blame others for "abusing" the RFC process while you've brought to us an RFC with a significant ambiguity [3] which you haven't mention and it turned out after closing a vote. Personally I think that it was your huge failure to bring the previous @@ syntax change RFC up to the voting without checking it's correctness. I'm personally also disappointed with the fact that in your RFC under the primary vote question "Are you okay with re-voting on the attribute syntax for PHP 8.0?" removing features like grouping ability was hidden. Personally I think you're forcing to stop the re-vote cause of mental connection to your previous @@ RFC and trying hard to find an argument against the re-vote. From the results which are available so far, it can be seen that your proposed syntax is no longer the leading one. I understand it fully cause I'd be upset as well. From my own experience, I know that as a RFC author there has always be a place to just let it go cause you won't always get to convince 50+ voters to your PoV. Cheers, Micha=C5=82 Marcin Brzuchalski [1]: https://externals.io/message/111218#111254 [2]: https://wiki.php.net/rfc#declined [3]: https://externals.io/message/110640#110819 [4]: https://externals.io/message/111101#111101 [5]: https://externals.io/message/111101#111132 --00000000000009f09205acbde17b--