[PHP-INTERNALS] Proposal to increase the required majority for all RFCs

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,

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

I don’t and can’t agree with this. Zend changes will ultimately affect everyone.

It is not just Zend maintainers who’ll be affected by the 64-bit patch, for example. Everyone would, as it would increase PHP’s memory usage.

Also, I am unconvinced that just because the people who maintain Zend (say) want something, that they are necessarily right.

all RFCs
In (the unlikely) case that Zend/ maintainers decide to do something that
negatively affects PHP - in this case memory usage - then it becomes
everyone's problem and everyone's entitled to a vote. But not before the
Zend/ maintainers see the implementation-only (feature-free) patch
suitable for inclusion in the engine, which wouldn't have happened here.
Similarly, if the docs guys decide to switch to another platform but the
generated docs remain unchanged - it's their and only their decision. If
as a part of that change then suddenly docs suddenly have bloated HTML
that takes 500MB of memory to render, then it's everyone's vote.

FWIW, rest assured this is purely theoretical matter. In 15+ years, I
don't think there was a single patch condoned by the Zend/ maintainers
that negatively affected performance without otherwise bringing tangible
value (typically in the form of new features, which are now voted on by
everyone). It's always the opposite - in a nutshell, Zend/ maintainers
are crazy for performance. And I'm sure the doc team wouldn't move to a
tool that emits such poor HTML either.

Zeev

Cannot agree more here. php4 to php5 and the later versions have
clearly show Zend blocking features that have beeb implemented later,
loosing years in the process. RFCs provide a way to reach consensus
and keep in touch with the reality of the PHP needs today and
tomorrow.

I think that the serious core changes require technical expertise before
voting (like Nikita made).
And the results of such expertise should be published in additional to RFC
on the same page.

Thanks. Dmitry.

So basically, based on what you say, many if not all new features in
5.4 or 5.5 would have been rejected per se because they were done by
new developers.

Sorry, I rather prefer to keep things like they are and improve/solve
confusing wording instead of going back to the benevolent dictators
time.

All developers make mistakes and they need to be verified by experts.
In most cases this process must lead not to rejection but to a better
solution.

Thanks. Dmitry.

Indeed, and things are getting better lately :)

We see RFCs from teams, new developers guided from more experienced
ones. This is the way to go.

But closing the doors to a small group of persons, with some of them
not contributing anything since quite some time, cannot work.

Hi!
Nobody is "necessarily right". If we could find a person who is always
right, we wouldn't need a vote - we'd just ask him (or her) and do as he
(or her) says. Instead, we have to try and find the right thing knowing
that everybody could be wrong, both individually and collectively.

And here we have a conundrum - who is likely to be right and wrong on
the matters dealing with deep engine implementation and requiring deep
expertise to get them right - people actually working with it or people
that, without diminishing their respective abilities and capabilities,
do not?

I agree that they need to be amended, but....

Requiring a supermajority for every single change wouldn't impede routine
progress, but it would impede meaningful progress. Why? Because it would
essentially prevent us from making a collective decision on any contentious
issue.

Just look at the United States Senate. They can't get anything done
because a 60% supermajority is required on just about everything now that
the filibuster has become routine. It's frustrating when 59% votes in
favor of a routine funding bill and it still fails. What you're talking
about would be an even greater hurdle, 2/3. Now I will concede that,
thankfully, we tend to get along better than members of the U.S. Senate,
but we're still human and we're still going to have heated disagreements on
issues that need to be addressed. If we start having RFCs failing with 65%
in favor of passage, that would have a paralyzing effect and we'd risk
falling into the same trap that befell the Senate.

They weren't always this dysfunctional. It used to be that 60% was only
required for major things with wider implications. Stuff actually got done
back then. Just like stuff gets done now in PHP. If we go to a 2/3-only
model, we'll make it impossible to make any collective executive decisions
on controversial matters. It's arbitrary (why 2/3 and not 60% or 55%?),
ignores the will of the majority, and is simply not sustainable.

A much better solution would be to amend the voting RFC to provide more
clarity as to when 2/3 is required and when it's not. The current language
is too vague and open to interpretation.

--Kris

My vote is for 66%+1 on engine and/or language changes and 50%+1 on side
changes.
If I want to suggest a Jsonable interface which purely affects a subset of
functions and nothing else, I don't think 66% is needed for change to go in.

My 2¢,

this is what I would consider reasonable too, with the extension than any
removal of existing (and documented) functionallity should also require 2/3
of the votes.

Agreed, except that we need to strengthen the wording by more specifically
stating what "engine and/or language changes" does and does not mean. It's
easy to agree on this in principle, but the devil is in the details. Right
now, there aren't any.

Also agreed.

--Kris