Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74294
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.220.180 cause and error)
References: <A3E9D7E0-5C10-48AD-B141-F3D72B74A235@ajf.me>
In-Reply-To: <A3E9D7E0-5C10-48AD-B141-F3D72B74A235@ajf.me>
MIME-Version: 1.0
Thread-Index: AQJEUJ97sMmembt+C+4/dyqcJc5t65pbagmQ
Date: Sat, 17 May 2014 22:46:00 +0300
Message-ID: <4818449979808f1f4d0fcdc1409d9e04@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] Proposal to increase the required majority for all RFCs
From: zeev@zend.com (Zeev Suraski)

I don't think that solves our problem.

For language changes - which are really new/altered features - 2/3 is
sufficient.  Another thing which probably makes sense is a 2/3 vote for
changing the voting rules - right now there's a bit of a loophole there :)

I think for things like new features in or modifications to extensions or
functions, changing release dates, version numbers, etc. - 50%+1 is
sufficient.  There's no major 'interruption to the status quo' and it's
more of a matter of opinion, and there's therefore no need for bias
towards that status quo.

Implementation changes don't fit in this RFC process too well.
Implementation changes should be dealt with by those who own the
implementation.  In this case, it would make sense for people with
Zend/TSRM karma to vote, but less so phpdoc or even pecl.  If there was an
RFC about a change for an implementation change in how we do docs (with no
meaningful impact on users) - then similarly, it should be voted on only
by people with phpdoc karma.  I'm honestly not so sure that such changes
even make sense for the RFC process at all, but if we decide to run
everything by that process, that's roughly how it should work.  One way
would be enforcing it;  But I think it'd be more appropriate if
implementation RFCs were clearly marked as such, clearly defined the
component(s) in question, and people figure out themselves whether this is
something they should vote over or not.

In the case of the 64-bit patch RFC, it'd probably be split to 2 or 3
separate RFCs.  One that deals with the user-impacting elements (integer
size) - which should obviously involve everyone.  On the other extreme end
- the parts of the patch that deal with the low-level data structures of
the engine that are of no concern to anybody but the engine developers,
like the hashtable and bucket size elements - which should involve people
with Zend/ karma.  And perhaps, something in between - the parts which
affect not just the engine but the APIs (macro renames, etc.) - which
should be open to people with php-src/ and pecl/ karma.

Simply pushing up the required majority for everything to 2/3 will not
truly solve the problem IMHO.  It would prevent decisions (with no
long-term effects) from passing, and it may still allow for groups seeing
their implementation forced to undergo a change by people who are neither
involved in its maintenance nor affected by the changes.

Zeev




> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Saturday, May 17, 2014 9:57 PM
> To: PHP internals
> Subject: [PHP-DEV] Proposal to increase the required majority for all
RFCs
>
> Good evening,
>
> Given the recent controversy on the 64-bit patch vote, and after some
> discussions on IRC[0] with some others, I think we should amend the
current
> voting rules[1].
>
> Currently only 50%+1, a simple majority, is required to pass
'non-language
> changes'. However, I feel that this is too small of a hurdle to pass.
Under this
> rule, contentious changes can pass despite a very thin majority. The
rationale
> seems to be that non-language changes have less broad effect and hence
don't
> need wide approval. However, changes which don't affect the 'language'
can
> still have wide-ranging effect and be very problematic. It is also a
quite vague
> requirement, as it is not always clear what change affects the
'language' and
> what doesn't.
>
> Hence, I propose that we require a supermajority of 2/3 to pass RFC
votes. This
> system is currently used for 'language' 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 will 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 would be no interpretation issues as to what
> constitutes a language change, as all changes must meet the same bar.
>
> To those who say this might impede progress, I would like to point out
that
> every single RFC accepted for PHP 5.6 so far was accepted by more than a
2/3
> majority, and so would not have been stopped by this hurdle. Also, I'm
not sure
> it is fair if 'progress' happens when there is not broad consensus on an
issue.
>
> There is not yet an RFC for this, as I want to discuss the concept
first. I'd also
> rather not talk about other aspects of voting reform in this thread if
possible,
> such as waiting periods or what karma is needed to vote, so I would ask
that you
> please make a separate thread for that.
>
> Thanks!
>
> [0] irc://irc.efnet.org/#php.pecl
> [1] https://wiki.php.net/rfc/voting
> --
> Andrea Faulds
> http://ajf.me/
>
>
>