Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104272 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 44681 invoked from network); 7 Feb 2019 11:57:31 -0000 Received: from unknown (HELO tbjjbihbhebb.turbo-smtp.net) (199.187.174.11) by pb1.pair.com with SMTP; 7 Feb 2019 11:57:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.net; s=turbo-smtp; x=1550133546; h=DomainKey-Signature:Received: Received:MIME-Version:References:In-Reply-To:From:Date: Message-ID:Subject:To:Cc:Content-Type; bh=N5rsZqBOR6YN+C+Yo3Tglx m4PDg3jan88920WQuaytE=; b=iLjOcQUcZfJeFG6PgUz0RrvTiwf8hZFkn/uct1 1NRfKxKfV3WPbahrxtwroypSvk0NT08jEmDC+sgMDXVOaGoJTRF3nXJ/KdoAnulT 43clw+sRm0B1L2XBAEf+T7kVWgNPBt1TtfmLsMz5QfQZJIB7IvfOUswLnqalkeq5 EXrZk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=turbo-smtp; d=php.net; h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type; b=UDHQiC/f3Er6v/JE04LINY0CQyzCLfMKalD24Bq61+K1ZfGiOYRGBwUBVRWPGH s96lP/yexegMjyk2YQ6iB1sQKU33XS3T7FpwuVO+jWFykdcRQps92vRXbF0ROd+P z3iZNcYsdwruB5J/i0r+mrS8SQC764MlpXhkENzUpW2ZQ=; Received: (qmail 25005 invoked from network); 7 Feb 2019 08:39:06 -0000 Received: X-TurboSMTP-Tracking: 4837186266 X-Gm-Message-State: AHQUAuYP19sYY3u5FL98Tsj4ZDQhX8BzBME5bkmQaSktxMRqKy5P22AM zFRBH8MPiZshrMALMlzWV0GiZH87WRa7e3jc4h8= X-Google-Smtp-Source: AHgI3IZZflv5hYfQY6fqWQujHxgwXbQQPU/+56rcRaomXU/WOrHCPBgAXD1GkvNnGcDyXFfCFP3RUbLoqf07CwZNEDw= X-Received: by 2002:a0c:c389:: with SMTP id o9mr11153870qvi.90.1549528745766; Thu, 07 Feb 2019 00:39:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 7 Feb 2019 10:38:54 +0200 X-Gmail-Original-Message-Id: Message-ID: To: Niklas Keller Cc: Nikita Popov , Joe Watkins , PHP internals Content-Type: multipart/alternative; boundary="00000000000075f66f058149c6ef" Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins From: zeev@php.net (Zeev Suraski) --00000000000075f66f058149c6ef Content-Type: text/plain; charset="UTF-8" On Wed, Feb 6, 2019 at 9:06 PM Niklas Keller wrote: > > I'll reiterate my main two issues with this RFC: > > - I do think that we need 50%+1 votes for certain decisions. Naming the > > next version of PHP, or even deciding to release it outside of the yearly > > cycle should not require a 2/3 vote. It's not so much erring on the side > > of being conservative - it's enforcing a bias for status-quo that simply > > doesn't exist in these issues. Is it the end of the world that we won't > > have it? No, but it's better that we would. > > - More importantly, the voting base issue must be solved before we change > > the voting rules. I find it extremely problematic process-wise that > we'll > > change the rules using a voting base that was never defined to be valid > in > > the first place. > > It's the only definition we currently have. That's not exactly true. We have the definition that was actually agreed upon in the original Voting RFC, and while it's hardly great - it's clearly different from the voting base we currently have in practice. > We have to rely on the > same voting base to change the voting base. I don't see how voting on > all other RFCs is fine, but voting on this one isn't. > Reality is I don't think it's fine for other RFCs either. I'm not claiming we should revisit each and every past RFC and start backtracking retroactively - but if we are to change the rules, we should do so comprehensively and fix this long outstanding issue. > > You mentioned that you don't see why the two issues are > > interlinked - and you may be right, it's more that one is dependent on > the > > other. Voting eligibility is the first question we should answer, and it > > should only be followed by the voting rules themselves. > > We currently have an answer to voting eligibility. It's one you may > not like, but changing that is completely independent of changing > voting margins. Again, in my opinion the answer we have is a de-facto answer that is both fundamentally flawed (that's the opinion part), but also entirely inconsistent with both the intention and text of the Voting RFC that is currently in effect (that's not a matter of opinion, that's fact). It also not completely independent. It has to do with the relative power of the code contributors, vs. folks who aren't code contributors who presently have a vote even though they're not supposed to have one based on the rules agreed upon back in the day. Zeev --00000000000075f66f058149c6ef--