On Mon, Sep 16, 2019 at 1:18 PM Benjamin Eberlei <kontakt@beberlei.de>
wrote:
>
> We heard you repeating the RFC process isn't applicable very often now,
> but a productive way forward needs to take it into account to make any
> change in governance.
>
I think it can actually be taken into account. As I wrote - we can
probably reuse much of it, in terms of voter eligibility, process, etc. -
but the clearance bar is simply unfit for the purpose. Again - not only
because it was never intended for that, but because it doesn't make any
sense.
> For many of the current contributors RFC+Voting process is the only
> visible process that was applied and has been used to make changes to the
> language in the last 8 years.
>
True, but for them - these two recent RFCs (short tags and even much more
so, the current proposal to do away with default values for undefined
variables) are the first instances of grandiose compatibility breakages
that affect a sizable percentage of the PHP userbase and codebase. Yes,
we've had some deprecations in the past that used this process - but they
all had very limited impact. None of them was even remotely close to
either of those.
>
> In these votes not arbitrary people, but the contributors with high
> influence, the current and recent release masters of PHP 5s and 7s have all
> participated, and many core code contributors have **overwhelmingly voted
> for the changes**. To me that makes the RFC process "common law" of the
> project, and gives the process a very high legitimacy across many current
> contributors, and outside by the community for all changes to the language
> and project.
>
As such any move to change that process, without using the RFC+voting
> process as the means to arrive such change, will lead to negative
> reactions. All the implicit process that may have existed before was not
> passed on to the current maintainers. That governance failure from 8 years
> ago is something you cannot take back anymore without sparking the stark
> reactions we see right now.
>
Again, there are no instances of radical governance changes - in fact, the
two RFCs that amended the Voting RFC in fact placed new limits on it (by
raising the bar), rather than extended its reach.
Similarly - none of the RFCs we voted on so far had an impact that is
remotely close to the two recent RFCs at hand. As Remi said - PHP 7 - the
first version to extensively use the RFC process, was a good version with
very good BC - with migrations relatively very straightforward. These two
RFCs are the first time the process is being used for something like that.
In fact, I'm hard pressed to think of *any* break that is at the same level
as the removal of default values for undefined variables. It's not only
something the likes of which we never voted on - we've never done something
like that, even before the RFC process was enacted.
So, it's not as if we've gotten used to making radical changes to the
project governance, or that we've been deprecating fundamental features
left and right - and now suddenly somebody's pulling the brakes. We
haven't been doing that. This is new stuff.
Would it be too much to ask accept the voting RFC as more than it was
> thought to be and move forward with your ideas about deprecations as an
> amendment to the RFC process?
>
It's already evolved to be more than what it was originally - which is OK.
But between something that governs slightly more than what it was intended
to - and something that governs everything and anything - there's still a
big gap.
> then we can finally productively discuss the exact wording that you are
> looking for and have a vote about it.
>
This isn't so much about wording. Reusing the procedures in the Voting RFC
is probably mostly fine - it's the bar that's problematic.
Let's ascend for a second from the procedural question and look at the
substance.
We're currently at a situation where it appears clear that there's a
majority of folks here that want to go in a certain direction, while
completely disregarding the minority. We're not talking about new features
(that the internals@ minority and beyond can dislike, but can simply choose
to ignore) - we're talking about radical changes to PHP that the internals@
majority wants to force on the internals@ minority, as well as the rest of
the world. There are no attempts being made to cater to the requests,
needs or concerns of the minority. In fact, many in the majority
repeatedly state that their goal is eliminating what the minority wants to
keep. Their win is the others' loss, by definition, purposely and
intentionally.
We are at a new stage - a stage where fundamental features that have been
with us for over 20 years are suddenly on the chopping block. We've never
done things like that with a 2/3 majority. It doesn't make sense to do
these things in a 2/3 majority. It's wrong, it's contentious, it's bad for
both life on internals@ and life beyond it. Even if the minority manages
to 'win' (after being forced to spend tons of energy just to defend the
status quo) - it creates widespread negative feelings in both camps. This
process virtually guarantees a very high number of losers - on both
internals@ and beyond.
One way to solve it is amending the Voting RFC to extend to high-impact
deprecations. We can use the existing voting mechanism for this, but much
like other times where we changed the rules - we need an overwhelming
majority to do that. I could be wrong, but my guess is that if we simply
explicitly add that radical compatibility-breaking language changes or
governance issues are simply covered as-is - it will not garner nearly the
same level of support that the original RFC and its two amendments won. We
need something virtually everyone can live with, not just two thirds of the
voters.
Another way (not mutually exclusive), which I personally think is better
for the range of topics we seem to be discussing lately - is to snap out of
the "your loss is my win" way of thinking. The folks who want to make PHP
stricter can get what they want and do it in an opt-in way - the way we've
always done things in PHP - without forcing everyone else to do the same.
This would make high-impact deprecations a very uncommon occurrence, ones
which will truly have a strong case (like register_globals and safe_mode) -
would likely garner very widespread support. Again, this is very very
doable. All it takes is some good will.
Zeev
