Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74291
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A3E9D7E0-5C10-48AD-B141-F3D72B74A235@ajf.me>
References: <A3E9D7E0-5C10-48AD-B141-F3D72B74A235@ajf.me>
Date: Sat, 17 May 2014 21:22:11 +0200
Message-ID: <CAEZPtU63=cz0eUWuvExY5p77_XiR=bbnZLFCW++XZywwjqGNJA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Proposal to increase the required majority for all RFCs
From: pierre.php@gmail.com (Pierre Joye)

On Sat, May 17, 2014 at 8:57 PM, Andrea Faulds <ajf@ajf.me> wrote:
> Good evening,
>
> Given the recent controversy on the 64-bit patch vote, and after some dis=
cussions on IRC[0] with some others, I think we should amend the current vo=
ting rules[1].
>
> Currently only 50%+1, a simple majority, is required to pass =E2=80=98non=
-language changes=E2=80=99. However, I feel that this is too small of a hur=
dle to pass. Under this rule, contentious changes can pass despite a very t=
hin majority. The rationale seems to be that non-language changes have less=
 broad effect and hence don=E2=80=99t need wide approval. However, changes =
which don=E2=80=99t affect the =E2=80=98language=E2=80=99 can still have wi=
de-ranging effect and be very problematic. It is also a quite vague require=
ment, as it is not always clear what change affects the =E2=80=98language=
=E2=80=99 and what doesn=E2=80=99t.



> Hence, I propose that we require a supermajority of 2/3 to pass RFC votes=
. This system is currently used for =E2=80=98language=E2=80=99 votes, but I=
 feel it ought to extend to everything. This a much bigger hurdle to climb =
over than only a simple majority, but it means that only changes with broad=
 consensus are likely to pass. It also means that the results of a vote wil=
l be less contentious, as there need to be at least twice as many votes in =
favour than against for it to pass. Finally, this change would mean there w=
ould be no interpretation issues as to what constitutes a language change, =
as all changes must meet the same bar.


Language changes was meant for new features in the language exposed to
the users, things we will have to maintain for ages (think safe_mode
and other new language constructs). Internals on the hand keep
changing without impact on userland, hence we won't have to keep using
one implementation for years.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org