On Tue, Apr 30, 2019 at 7:03 PM Levi Morrison <le...@php.net> wrote: > On Tue, Apr 30, 2019 at 9:01 AM Zeev Suraski <z...@php.net> wrote: > > > > On Tue, Apr 30, 2019 at 2:14 PM G. P. B. <george.bany...@gmail.com> > wrote: > > > > > On Mon, 29 Apr 2019 at 16:53, Zeev Suraski <z...@php.net> wrote: > > > > > >> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd <dan...@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
