Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103923 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 11373 invoked from network); 31 Jan 2019 18:47:54 -0000 Received: from unknown (HELO tbjjbihbhebb.turbo-smtp.net) (199.187.174.11) by pb1.pair.com with SMTP; 31 Jan 2019 18:47:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.net; s=turbo-smtp; x=1549553269; h=DomainKey-Signature:Received: Received:MIME-Version:References:In-Reply-To:From:Date: Message-ID:Subject:To:Cc:Content-Type; bh=HqCb6pBUURU1ccmL7TShgX HnLg0ifDvS9ZmPGkqiTJI=; b=kY8BVLQNvFQZ1oMmJxZRB3wnmopT2Po8/7Xn2o qttHwprQXYzazvw5TO2I+upc3VbsfVm4ShH+gCKlcb97bAiYGTQEef647xi5z3mr wYrh20vo25BNasT++s0tv3tGumlxHHhc0tAERRq0jPf5RV26j5oK7yL7LgduL7/p gy97Y= 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=QjSPphRQkGcnGCKWJ28pl0t0CRw4Kul5Fat+S5Aar4KDXS5/qkt5nEExeBGHFs c5IBxiWuJXurvZopaWSi4vx/NIKhFEuqr2yYEw0diiztzUf9tz3A2pQBiut85Zqm 4buW7K9wiwY28h8CQVIr5VH2JiyrkZruzfO1vSAK2gOic=; Received: (qmail 13780 invoked from network); 31 Jan 2019 15:27:49 -0000 Received: X-TurboSMTP-Tracking: 4824230674 X-Gm-Message-State: AJcUukdKSaorYUSIEndHROTwzKglUHrYmEHKmb0zcBvJU8bXW+tXijDJ LB7tb4WJUM/GqLKP9sZ1zw2JKLXSXB6oIpPhbNw= X-Google-Smtp-Source: ALg8bN6PwDLYw3v7rk0UVUIBT6qoQ96zlrfhrh8+iYUHGSJgGcO+eqrxCVqPIRFyZyAhn4WRIho5EOJt/Lhwz4B8apo= X-Received: by 2002:aed:202e:: with SMTP id 43mr35224806qta.27.1548948468611; Thu, 31 Jan 2019 07:27:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 31 Jan 2019 17:27:37 +0200 X-Gmail-Original-Message-Id: Message-ID: To: Nikita Popov Cc: Zeev Suraski , Joe Watkins , "internals@lists.php.net" Content-Type: multipart/alternative; boundary="0000000000003f41b00580c2ab56" Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins From: zeev@php.net (Zeev Suraski) --0000000000003f41b00580c2ab56 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 31, 2019 at 4:55 PM Nikita Popov wrote: > I agree with Joe here that we should handle the question of voting margins > separately. Your RFC is a much more comprehensive reform, which contains a > number of points that look highly controversial to me (such as the eligible > voter changes). It may take a long time until we reach a satisfactory > consensus there. > > On the other hand, this RFC is very simple and at least to me a complete > no-brainer. I already use 2/3 majority for all my votes, because I very > strongly believe that changes to PHP need to be held to a much higher > standard than a simple majority. It is outright shameful that functionality > can be added to PHP if 21 vote in favor and 20 against. That's not a > consensus, that's a complete disagreement. > > It's not necessary to decide all questions regarding the RFC process at > once. Voting threshold is a very self-contained issue and we can decide it > separately from other controversial changes. Well, I think there are several issues here. One - while the passing threshold is probably one of the most painful issues with the current Voting RFC, it's hardly the only one. Given it's taken us many years to start tackling this, I think it's safe to say that as a rule, we lack the motivation to tackle these issues. I think it's pretty clear that if we solve the threshold issue independently, it would likely be years before we tackle the other issues, if ever. Secondly - the threshold and voting eligibility are not, in any way, independent. They're two fundamental aspects of the same topic - how votes take place. A 2/3 majority out of a subset of ~200-300 people is very different from a 2/3 majority out of a potential group of several thousand people Thirdly - implementation issues - that the original Voting RFC did NOT intend to cover, later became covered by it by virtue of assumption. I think that implementation issues (implementing the same functionality that we have right now in a better way) should not be subject to a vote, and moving the threshold to 2/3 makes the current situation even worse than it currently is, and should be for the most part up to the maintainers of the code. So no, I don't think we can simply 'abolish narrow margins' without thinking about the implications as well as tackling the other shortcomings of the 2011 Voting RFC. With due respect, it reminds me of the hasty approach we took back then, and that wasn't good. Unless I'm missing something, we're currently in absolutely no hurry - we just released 7.3, we can spend as much time as needed (to a reason) on hashing out updated voting rules. I'm speaking on behalf of myself, and maybe Dmitry thinks differently - but I'm certainly fine waiting with that RFC for several weeks or even a couple of months if needed. Zeev --0000000000003f41b00580c2ab56--