Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103943
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=rkRviVqwW1zqIJ9+cdZ9rvXwzVVGlLvJTeem4bOQ+cgzSPup2j1ZJ3NLuxy/IJ
	u1UGwXqHIunFv6LxE89OCSBBRWsLr+v41eI3XJJUl8sLNZ0bvbTL7i3CS0lGG93e
	L5jgq8lmWPUj8jpD+fGNDg1rL+bKfKDWfwib5OQfFWtWI=;
MIME-Version: 1.0
References: <CAOwTYAsePeRLZZVK=QKftoOtug2_F=5bsti56z2mJfBXP0u4rw@mail.gmail.com> <DM6PR02MB5594D2DE0A166B13024E44B9AC910@DM6PR02MB5594.namprd02.prod.outlook.com> <CAF+90c84ukPn2AwGL5-8srOwO=8MhhgG7-BFGfw9t8oSZHb_2w@mail.gmail.com> <CAJHtzny4gBkfCS42SOup+GO-Nqd-xC-9S4k=JthFvBB134=Xzg@mail.gmail.com> <CAF+90c_bmePEVY7pAJmrDn0YThc-XQi7CZZLmMRy1XYDvAtYfw@mail.gmail.com>
In-Reply-To: <CAF+90c_bmePEVY7pAJmrDn0YThc-XQi7CZZLmMRy1XYDvAtYfw@mail.gmail.com>
Date: Thu, 31 Jan 2019 20:01:10 +0200
Message-ID: <CAJHtznw_2_Zzmg4tpk8LQRLCq07_iQ5aOBVPdJzqEN8B2U_LMA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000754c100580c4d05a"
Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins
From: zeev@php.net (Zeev Suraski)

--000000000000754c100580c4d05a
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 31, 2019 at 7:00 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> Let me reply to the last point first, because I think that's really the
> crux here: The issue is not that this RFC is very urgent per se, it's that
> it has already been delayed numerous times and it is imperative that we
> prevent that from happening again. Since this issue was first raised, a
> number of RFCs have passed with narrow voting margins. Every time that
> happens, I think "damn, why didn't we go through with the voting threshold
> RFC?"
>
> This RFC has been delayed for various reasons in the past -- those reasons
> sounded good at the time, but the end effect is still the same: RFCs being
> accepted with unreasonable margins. If we delay this again and it turns out
> that your competing RFC stays in limbo for the next two years, or is simply
> not accepted due to changes unrelated to voting margins, I would consider
> that to be quite unfortunate.
>

I've had similar issues with other aspects of the shortcoming of the 2011
Voting RFC.  The 50%+1 vs 2/3 is really just one issue - it's an important
one, but just one - and it doesn't live in vacuum.  It's interrelated to
other issues.


> If you have concerns with the details of the rules outlined in this RFC,
> I'm sure that Joe is open to discussing them. But let's please make sure
> that this particular question is resolved in a timely manner, which I think
> requires it to be tackled separately from other issues.
>

To me, changing the margins is like placing a band-aid on a gunshot wound.
Or perhaps to be more fair, it's to start surgery on wound, but then
stopping a 3rd way through or so.
Unless the RFC is extended to cover all the key shortcomings of the 2011
Voting RFC, then it's a superficial fix that I can't be in favor of.
 Rushing it through bears the hallmarks of the issues that plagued the 2011
Voting RFC - putting something together quickly, not trying to think
through all of the different scenarios and consequently not providing a
comprehensive solution.

Is the 2011 Voting RFC + permanent 2/3 margins still deeply flawed?  I'd
say absolutely yes.  Then let's think on how we fix it holistically.

If your concern is that RFCs would pass under this low margin as we debate
- why not call for a 30 day pause on RFC votes altogether (extensible by
another 30 days assuming there's still a healthy discussion), not just for
JIT?  I'm all for it.  We have the time and apparently now also the
inclination, let's finally settle this thing and make it right.

Zeev

--000000000000754c100580c4d05a--