On Tue, Apr 30, 2019 at 2:14 PM G. P. B. george.banyard@gmail.com
wrote:On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd Danack@basereality.com
wrote:Please stop doing this.
I will gladly do so, once the project starts behaving responsibly
again.Honnestly, this comment right here Zeev just makes me want to not
compromise at all.
I think you seriously lost any hope there was that I'm going to put
back
this to a vote.In retrospect, I should have waited for Dan's insulting message to wear
off
before replying to it.The fact the RFC included a confusing secondary vote, that was defined
against our RFC rules and may have been misunderstood by folks who voted
(and consequently may have resulted in different outcomes) - is
sufficient
grounds to disqualify this vote and require a restarted vote on a fixed
RFC
(that can include the amendments you have in mind to make the 8.0
behavior
different from what the RFC proposed).Zeev
I read our voting rules, checked with a few people, and thought about
it for a while, and I still do not know what rule breakage you are
referring to. How did this supposedly break our voting rules? If you
want any support on disqualifying this RFC, you need to clearly state
the violation.
The Voting RFC states:
"Additionally, an RFC may have secondary votes, which are used to decide
implementation details. " (emphasis added)
The RFC in question states:
"Secondary vote: Remove PHP's short open tags in PHP 8.0."
This is not an implementation detail or even remotely one. It's makes a
huge difference, arguably a lot bigger than the primary vote (which can be
fairly easily ignored by end users).
This is not a technicality. I found the voting options very confusing, and
I'm sure I wasn't the only one. In addition, I found it very weird that
many folks voted NOT to deprecate this feature in 7.4, but voted in favour
of removing it in 8.0 - which doesn't go against any of our RFCs (at least
if my memory serves me right), but does go against the way we've been
handling deprecations in the last ~15 years - you never remove a feature
without deprecating it first. So in addition to stating a secondary vote
for something that had to be a primary vote - the 'original' primary vote
(deprecate in 7.4) is in fact an inherent requirement if the secondary vote
passes - but judging from people's votes, it's clear it wasn't properly
understood. George has a reasonable interpretation as to what this meant -
but it's just one possible interpretation.
Ultimately, the voting decisions were flawed and against two of our rules
(one written, and one de-facto) - which means that needs to be fixed and
redone. It's impossible to know what kind of impact laying out the voting
options properly would have had (it goes in both directions, by the way -
it may have resulted in a higher majority - or a lower one, pushing it
below the threshold).
On the substance level - I think it's clear even to the pro-deprecation
crowd that this RFC was created in haste. There was very little discussion
over it, so little that the fact that the fact that outright removing short
tags in 8.0 (as opposed to turning them into errors) would have
catastrophic consequences wasn't even discussed.
I've heard from several folks that the right way to address this is with a
new RFC that will supercede this one. I agree, but it should be the
authoritative RFC with the current one being annulled - given the flawed
voting options. We need a new RFC that fixes the flaws of the current one
- both in terms of substance (8.0 behavior) and voting options.
Zeev