Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102785
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
References: <CAL=_i_ngW=NOe=T8VKReF7ov-3OhRM228QFZyWfg5aWPw9uSdQ@mail.gmail.com>
 <c5fb1d3e-e31a-88b5-a2fa-c87dd8471c39@gmail.com> <38809703-3aa1-34cf-82b9-019ee8788cb9@gmx.de>
 <CAESVnVrZCGTZ3mSWPirCCxu-NCOaO9MSffz2wE7rsQYWjVYEww@mail.gmail.com>
 <58.E2.57182.05E864B5@pb1.pair.com> <CAESVnVp8JfhpWJBN1dz+LxDd_qaiHDoBMSATRitnrV3Lot1-ZA@mail.gmail.com>
 <CAL=_i_kRmNZLvwh6XDCMKYc55W9kMT-rVz6CKqaeQ+AdBgPf-w@mail.gmail.com>
In-Reply-To: <CAL=_i_kRmNZLvwh6XDCMKYc55W9kMT-rVz6CKqaeQ+AdBgPf-w@mail.gmail.com>
Date: Thu, 12 Jul 2018 11:10:00 +0300
Message-ID: <CAJHtznxEUAdLTDYTqNj7y7RiBuP9xhns1cczBEKSZZvoMxEpPg@mail.gmail.com>
To: pthreads@pthreads.org
Cc: Sara Golemon <pollita@php.net>, ajf@ajf.me, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006ffa110570c8e41a"
Subject: Re: [PHP-DEV] [RFC] abolish narrow margins
From: vsuraski@gmail.com (Zeev Suraski)

--0000000000006ffa110570c8e41a
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 12, 2018 at 7:38 AM Joe Watkins <pthreads@pthreads.org> wrote:

> Zeev,
>
> > I think our voting rules are in need of a much thorough review than just
> pushing the limit to 2/3 - which also IMHO doesn't tackle the difference
> scenarios that exist out there.
>
> Agree, they need reform, but rather than trying to discuss and pass a
> monolithic RFC that tries to solve all problems, I chose (a year ago) to
> start here; Simply raising the bar simplifies the rules we currently have
> and so simplifies their reform (in detail and process).
>

I think the problem is that there are cases where a 2/3 vote (or a vote at
all) doesn't make sense.  True, we didn't have too many of those in the
past - but as we reform, I think it's important to take note of them.
Things which don't effect the language, but are more of a question of
preference - e.g., the decision to name phpng as PHP 6 vs PHP 7 - or for
that matter, deciding about a different release cadence.  It's one thing to
add a language construct, to change the behavior of a function or to
add/remove an extension - this bubbles into people's code and we'd have to
live with this decision and its implications even in a decade's time -
while we can change our release cadence 3 times in between (if we wanted
to), and obviously whether phpng ended up being called PHP 6 or PHP 7 had
no technical meaning, only a 'marketing' one.  Then there are also
implementation decisions - where things in the past have been a bit unclear
- and I think it's needed to clarify that such decisions (including
substantial refactoring, as long as there's no negative end-user impact)
should not require voting, but are up for the folks actually maintaining
that particular piece of code to decide.
So while I think non 2/3 votes would be uncommon, I do think we need to
have provisions for them - and voting to make everything 2/3 right now
without discussing the wider scope is wrong IMHO.

Also while generally I very much agree with the 'agile' sentiment of fixing
things gradually instead of in one monolithic step - our voting rules are
so lacking that it feels like putting a band aid on a gunshot wound...
By the way, I still think there's a lot of work that still needs to happen
on my proposal - perhaps factor in quorums, how votes relate to deadlines -
we can probably learn quite a bit from our experience including in recent
weeks - but I think it's mature enough for others to comment on it, and I
would be very happy for others to join me in drafting it.

I'm not following your logic for further delaying voting on this RFC, in
> fact I don't see any logic, just an assertion ;)


Here's one example of our lacking rules (IMHO of course) - this has been in
the attic for just under a year, and now we're considering to just move it
to a vote within days.  I don't think that should be possible :)  The way I
see it, the voting period has to happen immediately after the mandatory
discussion period - and in a very predictable manner .  If an RFC goes
dormant, there should be a new discussion period prior to voting.

On my logic for not dealing with it right now, it's twofold:
1. There's too much activity going on around last minute 7.3 RFCs for many
people to have the bandwidth to discuss it in a serious manner.
2. It seems wrong to change the rules mid-flight in a way which might
affect the current 7.3 votes which are already under way (not that I think
it will affect most of them - but it still seems wrong).

Sorry for not actually mentioning that previously :)

Zeev

--0000000000006ffa110570c8e41a--