Hey, to clarify what the way to go with this RFC is.
This RFC is a FALLBACK. It's about the common part of both other RFCs.
That way it only will go to vote after Anthonys RFC ends. And only if it fails.
That means, I will go by the voting RFC and wait until discussion period ends and put it to vote after Anthony closes his RFC in case it fails.
I'm aware that a few people have said, they will change their vote depending on what ever might pass. And that they asked for this RFC going into direct competition against Anthonys RFC. No. Know what you want. If you dislike Anthonys RFC, vote no on it. If you like it, vote yes on it. But don't switch your votes back and forth depending on what might win.
That's why I decided to not have the vote on this running concurrently with Anthonys.
But, in any case this RFC will go to vote on the 24th if Anthonys RFC couldn't gather a 2/3 supermajority.
Thanks,
Bob
Bob,
Thanks for the update. This time, though, although I completely respect
your decision not to put your RFC into a vote unless the Dual STH mode
fails, I'd like to either (with your permission) take over the RFC or
propose my own copy and move it to voting as soon as allowed. This, under
a commitment that if I see that Basic STH is failing to garner a clear
majority, I'll retract it and move to support the Dual STH RFC instead for
the sake of unity.
Why am I making this admittedly big move? I think that waiting until we
know for certain whether the Dual Mode STH would win is very problematic,
for two reasons.
The bigger one that it runs a serious risk we have no STH at all for 7.0.
It's not an unlikely scenario either - it's probably 50/50% that the Dual
STH RFC would fail, only to find later - when it's too late - that Strict
campers have enough votes to block the Basic one. Personally, I find that
the worst possible outcome, given how clearly it is that the users at
large want something. If the Basic RFC is put to a vote but retracted
if & when we see it stands no chance to pass - combined with my commitment
to support the Dual STH in such a case (and my belief that move will be
able to influence others as well), the chances that we'd be left with no
STH at all for 7.0 goes down significantly.
There's also a secondary reason - I do think it's unfair that in a very
likely scenario - we won't be giving people who prefer Basic STH only - at
least at this point - a chance to vote at the proposal they think is best.
I don't think it's a matter of voting for "who's going to win"; In fact
with a commitment to retract it if it fails to win, it's not about that at
all. It's being able to vote for what you truly believe in, as opposed to
a compromise that you find bad but better than nothing. And in my case
(and perhaps others) - it's about being willing to vote for something I
actually don't believe it at all for the sake of unity, but only once the
alternative options have been explored.
Before Dual STH supporters dissect my move to pieces, please realize this:
If you're right - that Basic STH stands no chance to gain 2/3 majority -
you have absolutely NOTHING to lose, and in fact, you're increasing your
chances of passing that vote through from apparently 50/50 to 80/20 (not
talking about votes, but chances), and as a bonus, you get to prove your
point.
If you're wrong - and Basic STH is more popular than Dual STH (at this
point in time) - we would have given the community at large something
that's closer to what it really wants.
Zeev
-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Sunday, March 15, 2015 5:51 PM
To: PHP Internals
Subject: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesHey, to clarify what the way to go with this RFC is.
This RFC is a FALLBACK. It's about the common part of both other RFCs.
That way it only will go to vote after Anthonys RFC ends. And only
if it
fails.That means, I will go by the voting RFC and wait until discussion period
ends
and put it to vote after Anthony closes his RFC in case it fails.I'm aware that a few people have said, they will change their vote
depending
on what ever might pass. And that they asked for this RFC going into
direct
competition against Anthonys RFC. No. Know what you want. If you dislike
Anthonys RFC, vote no on it. If you like it, vote yes on it. But don't
switch
your votes back and forth depending on what might win.
That's why I decided to not have the vote on this running concurrently
with
Anthonys.But, in any case this RFC will go to vote on the 24th if Anthonys RFC
couldn't
gather a 2/3 supermajority.Thanks,
BobTo unsubscribe,
visit:
http://www.php.net/unsub.php
Am 15.03.2015 um 17:55 schrieb Zeev Suraski zeev@zend.com:
Bob,
Thanks for the update. This time, though, although I completely respect
your decision not to put your RFC into a vote unless the Dual STH mode
fails, I'd like to either (with your permission) take over the RFC or
propose my own copy and move it to voting as soon as allowed. This, under
a commitment that if I see that Basic STH is failing to garner a clear
majority, I'll retract it and move to support the Dual STH RFC instead for
the sake of unity.Why am I making this admittedly big move? I think that waiting until we
know for certain whether the Dual Mode STH would win is very problematic,
for two reasons.The bigger one that it runs a serious risk we have no STH at all for 7.0.
It's not an unlikely scenario either - it's probably 50/50% that the Dual
STH RFC would fail, only to find later - when it's too late - that Strict
campers have enough votes to block the Basic one. Personally, I find that
the worst possible outcome, given how clearly it is that the users at
large want something. If the Basic RFC is put to a vote but retracted
if & when we see it stands no chance to pass - combined with my commitment
to support the Dual STH in such a case (and my belief that move will be
able to influence others as well), the chances that we'd be left with no
STH at all for 7.0 goes down significantly.There's also a secondary reason - I do think it's unfair that in a very
likely scenario - we won't be giving people who prefer Basic STH only - at
least at this point - a chance to vote at the proposal they think is best.
I don't think it's a matter of voting for "who's going to win"; In fact
with a commitment to retract it if it fails to win, it's not about that at
all. It's being able to vote for what you truly believe in, as opposed to
a compromise that you find bad but better than nothing. And in my case
(and perhaps others) - it's about being willing to vote for something I
actually don't believe it at all for the sake of unity, but only once the
alternative options have been explored.Before Dual STH supporters dissect my move to pieces, please realize this:
If you're right - that Basic STH stands no chance to gain 2/3 majority -
you have absolutely NOTHING to lose, and in fact, you're increasing your
chances of passing that vote through from apparently 50/50 to 80/20 (not
talking about votes, but chances), and as a bonus, you get to prove your
point.
If you're wrong - and Basic STH is more popular than Dual STH (at this
point in time) - we would have given the community at large something
that's closer to what it really wants.Zeev
-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Sunday, March 15, 2015 5:51 PM
To: PHP Internals
Subject: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesHey, to clarify what the way to go with this RFC is.
This RFC is a FALLBACK. It's about the common part of both other RFCs.
That way it only will go to vote after Anthonys RFC ends. And only
if it
fails.That means, I will go by the voting RFC and wait until discussion period
ends
and put it to vote after Anthony closes his RFC in case it fails.I'm aware that a few people have said, they will change their vote
depending
on what ever might pass. And that they asked for this RFC going into
direct
competition against Anthonys RFC. No. Know what you want. If you dislike
Anthonys RFC, vote no on it. If you like it, vote yes on it. But don't
switch
your votes back and forth depending on what might win.
That's why I decided to not have the vote on this running concurrently
with
Anthonys.But, in any case this RFC will go to vote on the 24th if Anthonys RFC
couldn't
gather a 2/3 supermajority.Thanks,
Bob
Please do not top post...
Zeev,
I'm sure we risk to have no STH at all in PHP 7.0 if I put it into vote now.
Some people will change their vote, not enough people for basic to pass.
Also, I definitely won't support going back and forth with the votes.
If you have issues with dual mode, vote against it. If you like the Basic Types RFC, vote in favor of it, once it starts. You're all given a chance.
We should have a version of STH we have consensus on, not some type of STH most people dislike, just for the sake of it. Please respect my stance on that.
Thus, I deny your request and strongly urge you to not fork my RFC. That would be sabotaging of Anthony's and my RFC.
I won't tolerate that.
You had a time to do this RFC, but you did coercive. Now, it's my move with this RFC and not yours.
Please accept that and don't play against us.
Thanks,
Bob
-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Sunday, March 15, 2015 7:51 PM
To: Zeev Suraski
Cc: PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesZeev,
I'm sure we risk to have no STH at all in PHP 7.0 if I put it into vote
now.
Some people will change their vote, not enough people for basic to pass.
Also, I definitely won't support going back and forth with the votes.
If you have issues with dual mode, vote against it. If you like the
Basic Types
RFC, vote in favor of it, once it starts. You're all given a chance.
I don't view this as a purely technical vote, and I don't think our
community does either. It goes well beyond technology - if we fail to add
STH in 7.0, it will be perceived as a major disappointment for the
userbase and supposed proof that the project is unable to reach decisions.
The plan you propose greatly increases the danger of that, because we have
zero visibility into how people would vote.
Clearly, a lot of people here disagree with you about the concept of going
back & forth on votes. They view it as fair and warranted under the
current situation, where we don't have a better way of resolving a
conflict between competing RFCs. The availability of the Basic option
will affect the vote on Dual Mode, they're not independent. It's not
ideal, but that's the mechanism we have for now.
We should have a version of STH we have consensus on, not some type of
STH most people dislike, just for the sake of it. Please respect my
stance on
that.
I agree, except it's not an option with the plan you propose. None of
these proposals is going to have consensus, in the accepted sense (an idea
or opinion that is shared by all the people in a group, according to
Meriam Webster). The Dual Mode STH, if it wins, will still have more 'no'
voters than 'yes' votes casted for almost every other RFC. It will be a
majority - a special majority - but very far from consensus.
I'm also not at all sure that the Basic STH RFC - if you put it to a vote
- will win something that's close to consensus.
In fact, the only scenario where I see a chance for something that's
closer to consensus is if we try to put the Basic out to a vote; On one
scenario, we may see that a lot more people prefer Basic to Dual, and do
the community a big service. On the other scenario - we'd see that it
does nothing but further split the vote, retract it, and unite behind
Dual. Whichever direction it takes - our chances of hitting something
close to consensus goes significantly higher.
Thus, I deny your request and strongly urge you to not fork my RFC.
That
would be sabotaging of Anthony's and my RFC.
I won't tolerate that.
Anthony welcomed competing RFCs, and in fact proposed it. I don't see how
it would be sabotaging your RFC - when in fact it gives it a chance to
pass in a case Dual Mode manages to garner.
You had a time to do this RFC, but you did coercive.
Correct, as I knew that Basic STH was strictly opposed by a lot of strict
campers, and wanted to try to come up with a solution that would cater to
both camps' needs. Going with Basic would have been easiest, but I
thought it could reach something much closer to consensus - and failed.
Reproposing Andrea's v0.1 RFC definitely came to my mind, but I did not
recall the language in the Timeline RFC effectively allowing for RFCs to
be proposed until the 15th until you brought it up. Does it make sense to
you that the community may be barred from voting on this extremely
important topic because you proposed it but refuse to put it to a vote?
Now, it's my move with
this RFC and not yours.Please accept that and don't play against us.
Despite what I said, I am going to think about this hard. Still 3:15
hours of March 15th on this part of the planet.
At the same time - I urge you to also think hard about it and reconsider,
and put it to a vote as soon as allowed for the reasons mentioned above
and in my previous post.
Zeev
Zeev,
Thus, I deny your request and strongly urge you to not fork my RFC.
That
would be sabotaging of Anthony's and my RFC.
I won't tolerate that.Anthony welcomed competing RFCs, and in fact proposed it. I don't see how
it would be sabotaging your RFC - when in fact it gives it a chance to
pass in a case Dual Mode manages to garner.
I welcomed competing RFCs according to the accepted process a month
ago (http://marc.info/?l=php-internals&m=142383869529695&w=2). I
even extended voting on my RFC as a show of good faith. Please don't
abuse that good faith to political ends.
Anthony
-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Sunday, March 15, 2015 9:00 PM
To: Zeev Suraski
Cc: Bob Weinand; PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesAnthony welcomed competing RFCs, and in fact proposed it. I don't see
how it would be sabotaging your RFC - when in fact it gives it a
chance to pass in a case Dual Mode manages to garner.I welcomed competing RFCs according to the accepted process a month
ago (http://marc.info/?l=php-internals&m=142383869529695&w=2). I
even extended voting on my RFC as a show of good faith. Please don't abuse
that good faith to political ends.
There's nothing political about this and I do wish you stop portraying it as
such. Instead of welcoming my proposal to get behind your (IMHO bad)
proposal, you're calling me political. Can you commit to support the Basic
STH proposal if it gains something that's close to majority and more votes
than Dual? For the sake of unity?
Whether it was a month ago or today is meaningless. You did propose the
concept, and it applies for as long as RFCs can be handed in, which is
today.
Zeev
Zeev,
There's nothing political about this and I do wish you stop portraying it as
such. Instead of welcoming my proposal to get behind your (IMHO bad)
proposal, you're calling me political. Can you commit to support the Basic
STH proposal if it gains something that's close to majority and more votes
than Dual? For the sake of unity?
No, I will not support it.
Because I feel it's bad for the language. Getting something in
should not be our goal. Our goal should be getting the right thing in.
The reason I went the dual mode was because I finally understood
people needs. Or at least I think I do. And judging from the
conversations I've had with people who took the time to understand the
proposal (rather than jumping on FUD), I've seen enough evidence to
support that, rather than refute it.
Voting for something you don't think is right isn't unity. It's simply
trying to make yourself look good.
Whether it was a month ago or today is meaningless. You did propose the
concept, and it applies for as long as RFCs can be handed in, which is
today.
Uh huh.
Anthony
-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Sunday, March 15, 2015 9:22 PM
To: Zeev Suraski
Cc: PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesVoting for something you don't think is right isn't unity. It's simply
trying to
make yourself look good.
I don't think you understand the meaning of unity, but I'll let internals be
the judge of that.
Zeev
I don't think you understand the meaning of unity, but I'll let internals
be
the judge of that.
Judging.. judging..
-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Sunday, March 15, 2015 9:22 PM
To: Zeev Suraski
Cc: PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesVoting for something you don't think is right isn't unity. It's simply
trying to
make yourself look good.I don't think you understand the meaning of unity, but I'll let internals
be
the judge of that.
Zeev, it is enough now. You have been playing on the line way too long, for
all 7 RFCs. Stop now.
You keep saying that you are willing a compromise and we would have one
already with Anthony's RFC.
I have warned you about your 7 timeline proposal, how unrealistic it is.
You kept saying that we have to be strict. Now, all of a sudden, we have to
be flexible.
You want to continue? Fine, but be prepared to divide the community in a
very bad way. The rules are the same for everyone, no matter the price a
company or individuals have to pay for that.
I strongly suggest you to stop this madness now. That won't end well for
PHP.
Zeev
Bob,
Thanks for the update. This time, though, although I completely respect
your decision not to put your RFC into a vote unless the Dual STH mode
fails, I'd like to either (with your permission) take over the RFC or
propose my own copy and move it to voting as soon as allowed. This, under
a commitment that if I see that Basic STH is failing to garner a clear
majority, I'll retract it and move to support the Dual STH RFC instead for
the sake of unity.Why am I making this admittedly big move? I think that waiting until we
know for certain whether the Dual Mode STH would win is very problematic,
for two reasons.The bigger one that it runs a serious risk we have no STH at all for 7.0.
It's not an unlikely scenario either - it's probably 50/50% that the Dual
STH RFC would fail, only to find later - when it's too late - that Strict
campers have enough votes to block the Basic one. Personally, I find that
the worst possible outcome, given how clearly it is that the users at
large want something. If the Basic RFC is put to a vote but retracted
if & when we see it stands no chance to pass - combined with my commitment
to support the Dual STH in such a case (and my belief that move will be
able to influence others as well), the chances that we'd be left with no
STH at all for 7.0 goes down significantly.There's also a secondary reason - I do think it's unfair that in a very
likely scenario - we won't be giving people who prefer Basic STH only - at
least at this point - a chance to vote at the proposal they think is best.
I don't think it's a matter of voting for "who's going to win"; In fact
with a commitment to retract it if it fails to win, it's not about that at
all. It's being able to vote for what you truly believe in, as opposed to
a compromise that you find bad but better than nothing. And in my case
(and perhaps others) - it's about being willing to vote for something I
actually don't believe it at all for the sake of unity, but only once the
alternative options have been explored.Before Dual STH supporters dissect my move to pieces, please realize this:
If you're right - that Basic STH stands no chance to gain 2/3 majority -
you have absolutely NOTHING to lose, and in fact, you're increasing your
chances of passing that vote through from apparently 50/50 to 80/20 (not
talking about votes, but chances), and as a bonus, you get to prove your
point.
If you're wrong - and Basic STH is more popular than Dual STH (at this
point in time) - we would have given the community at large something
that's closer to what it really wants.Zeev
-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Sunday, March 15, 2015 5:51 PM
To: PHP Internals
Subject: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesHey, to clarify what the way to go with this RFC is.
This RFC is a FALLBACK. It's about the common part of both other RFCs.
That way it only will go to vote after Anthonys RFC ends. And only
if it
fails.That means, I will go by the voting RFC and wait until discussion period
ends
and put it to vote after Anthony closes his RFC in case it fails.I'm aware that a few people have said, they will change their vote
depending
on what ever might pass. And that they asked for this RFC going into
direct
competition against Anthonys RFC. No. Know what you want. If you dislike
Anthonys RFC, vote no on it. If you like it, vote yes on it. But don't
switch
your votes back and forth depending on what might win.
That's why I decided to not have the vote on this running concurrently
with
Anthonys.But, in any case this RFC will go to vote on the 24th if Anthonys RFC
couldn't
gather a 2/3 supermajority.Thanks,
BobTo unsubscribe,
visit:
http://www.php.net/unsub.php--
Hello,
I like your idea, but there's a problem with this (apart from the
thing that it's not supposed to be in vote for 7.0 if you go by the
rules, based on opinion of some people here).
You are saying "we would have given the community at large something
that's closer to what it really wants", but the people maintaining PHP
vote on that, not the community and userland developers (and that's a
problem with most of the features here, that the "direction" in which
PHP evolves is basically chosen by C programmers*).
*) Don't take it too literally or offensively please, but I hope
you'll get what I mean. :)
Regards
Pavel Kouril
-----Original Message-----
From: Pavel Kouřil [mailto:pajousek@gmail.com]
Sent: Sunday, March 15, 2015 7:52 PM
To: Zeev Suraski
Cc: Bob Weinand; PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesI like your idea, but there's a problem with this (apart from the thing
that it's
not supposed to be in vote for 7.0 if you go by the rules, based on
opinion of
some people here).You are saying "we would have given the community at large something
that's closer to what it really wants", but the people maintaining PHP
vote on
that, not the community and userland developers (and that's a problem with
most of the features here, that the "direction" in which PHP evolves is
basically chosen by C programmers*).
That is factually incorrect. C coders are a small minority amongst the
voters on this RFC - you can check it yourself by clicking on each voter and
seeing what Karma they have.
Also, the majority of C contributors also develop or developed in PHP as
well (myself included).
Zeev
Bob,
Thanks for the update. This time, though, although I completely respect
your decision not to put your RFC into a vote unless the Dual STH mode
fails, I'd like to either (with your permission) take over the RFC or
propose my own copy and move it to voting as soon as allowed. This, under
a commitment that if I see that Basic STH is failing to garner a clear
majority, I'll retract it and move to support the Dual STH RFC instead for
the sake of unity.
No one individual has the right to break the existing rules around
voting. There has been more than sufficient time to date to rewrite
the voting rules, debate voting rights, extend PHP7's deadline, or
propose the basic RFC so described. A vote in contravention of the
voting rules at the last possible minute cannot, by definition, be
recognised at this time. I wouldn't even vote since it might lend it
an air of ill deserved legitimacy, forgetting for a moment whether a
few PEAR contributions make me any more deserving of a vote than
others.
I recognise that the rules are inconvenient in the current situation
when time is in short supply, but that is why we have rules to offset
the temptation of doing things considered socially unacceptable. They
were voted on, they were adopted, and they remain adopted. There is
only one way in which they may be unadopted. Another RFC. Yes, PHP,
this is a government bureaucracy at work ;).
I'm not a lawyer, and I wouldn't appreciate the intended spirit of the
rules. Unfortunately, we don't have judges or juries, so all we can do
is abide by the letter of the rules as written, a contract all of us
have with the PHP community. Is that a perfect approach? Hell, no.
What is? It's just the only approach we can possibly follow on Sunday,
March 15th.
If this RFC enters into voting in any time period not allowed within
the rules as they are written, I will obviously not recognise it as
valid in any way.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
-----Original Message-----
From: Pádraic Brady [mailto:padraic.brady@gmail.com]
Sent: Sunday, March 15, 2015 9:00 PM
To: Zeev Suraski
Cc: Bob Weinand; PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesBob,
Thanks for the update. This time, though, although I completely
respect your decision not to put your RFC into a vote unless the Dual
STH mode fails, I'd like to either (with your permission) take over
the RFC or propose my own copy and move it to voting as soon as
allowed. This, under a commitment that if I see that Basic STH is
failing to garner a clear majority, I'll retract it and move to
support the Dual STH RFC instead for the sake of unity.No one individual has the right to break the existing rules around voting.
There has been more than sufficient time to date to rewrite the voting
rules,
debate voting rights, extend PHP7's deadline, or propose the basic RFC so
described. A vote in contravention of the voting rules at the last
possible
minute cannot, by definition, be recognised at this time. I wouldn't even
vote
since it might lend it an air of ill deserved legitimacy, forgetting for a
moment whether a few PEAR contributions make me any more deserving of
a vote than others.
No rule is being broken.
The PHP 7 timeline RFC (wiki.php.net/rfc/php7timeline) states the following:
Line up any remaining RFCs that target PHP 7.0. | Now - Mar 15 (4+
additional months)
As Bob pointed out, what 'Line up' means - whether it means vote ends, vote
begins, or discussion begins - is completely open to interpretation. I
don't remember what I meant when I wrote it, but arguably, 'line up' is a
lot closer to 'start discussing' than 'finish voting', and as is typically
the case when something is unclear, the most lax interpretation is
acceptable.
Zeev
Zeev,
-----Original Message-----
From: Pádraic Brady [mailto:padraic.brady@gmail.com]
Sent: Sunday, March 15, 2015 9:00 PM
To: Zeev Suraski
Cc: Bob Weinand; PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesBob,
Thanks for the update. This time, though, although I completely
respect your decision not to put your RFC into a vote unless the Dual
STH mode fails, I'd like to either (with your permission) take over
the RFC or propose my own copy and move it to voting as soon as
allowed. This, under a commitment that if I see that Basic STH is
failing to garner a clear majority, I'll retract it and move to
support the Dual STH RFC instead for the sake of unity.No one individual has the right to break the existing rules around voting.
There has been more than sufficient time to date to rewrite the voting
rules,
debate voting rights, extend PHP7's deadline, or propose the basic RFC so
described. A vote in contravention of the voting rules at the last
possible
minute cannot, by definition, be recognised at this time. I wouldn't even
vote
since it might lend it an air of ill deserved legitimacy, forgetting for a
moment whether a few PEAR contributions make me any more deserving of
a vote than others.No rule is being broken.
The PHP 7 timeline RFC (wiki.php.net/rfc/php7timeline) states the following:
Line up any remaining RFCs that target PHP 7.0. | Now - Mar 15 (4+
additional months)As Bob pointed out, what 'Line up' means - whether it means vote ends, vote
begins, or discussion begins - is completely open to interpretation. I
don't remember what I meant when I wrote it, but arguably, 'line up' is a
lot closer to 'start discussing' than 'finish voting', and as is typically
the case when something is unclear, the most lax interpretation is
acceptable.
By your own words: http://marc.info/?l=php-internals&m=142451267910615&w=2
Following Adam's analysis of the timeline, taking the more 'strict' (no pun intended!) interpretation of the timeline RFC, we still have until tomorrow to start the discussion and still target it for 7.0, no? Given the importance of this topic, I'd go for the more lax interpretation that allows for votes to begin by March 15, giving us all a bit more time to discuss.
votes to begin by March 15. That was the interpretation you used a
month ago.
Anthony
-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Sunday, March 15, 2015 9:11 PM
To: Zeev Suraski
Cc: Pádraic Brady; PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesZeev,
-----Original Message-----
From: Pádraic Brady [mailto:padraic.brady@gmail.com]
Sent: Sunday, March 15, 2015 9:00 PM
To: Zeev Suraski
Cc: Bob Weinand; PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesBob,
Thanks for the update. This time, though, although I completely
respect your decision not to put your RFC into a vote unless the
Dual STH mode fails, I'd like to either (with your permission) take
over the RFC or propose my own copy and move it to voting as soon
as allowed. This, under a commitment that if I see that Basic STH
is failing to garner a clear majority, I'll retract it and move to
support the Dual STH RFC instead for the sake of unity.No one individual has the right to break the existing rules around
voting.
There has been more than sufficient time to date to rewrite the
voting rules, debate voting rights, extend PHP7's deadline, or
propose the basic RFC so described. A vote in contravention of the
voting rules at the last possible minute cannot, by definition, be
recognised at this time. I wouldn't even vote since it might lend it
an air of ill deserved legitimacy, forgetting for a moment whether a
few PEAR contributions make me any more deserving of a vote than
others.No rule is being broken.
The PHP 7 timeline RFC (wiki.php.net/rfc/php7timeline) states the
following:
Line up any remaining RFCs that target PHP 7.0. | Now - Mar 15 (4+
additional months)As Bob pointed out, what 'Line up' means - whether it means vote ends,
vote begins, or discussion begins - is completely open to
interpretation. I don't remember what I meant when I wrote it, but
arguably, 'line up' is a lot closer to 'start discussing' than 'finish
voting', and as is typically the case when something is unclear, the
most lax interpretation is acceptable.By your own words: http://marc.info/?l=php-
internals&m=142451267910615&w=2Following Adam's analysis of the timeline, taking the more 'strict' (no
pun
intended!) interpretation of the timeline RFC, we still have until
tomorrow to
start the discussion and still target it for 7.0, no? Given the
importance of
this topic, I'd go for the more lax interpretation that allows for votes
to
begin by March 15, giving us all a bit more time to discuss.votes to begin by March 15. That was the interpretation you used a
month ago.
Anthony,
I did not read my own words and therefore didn't notice an even more lax
interpretation was possible. What you can see is that I always lean towards
the lax interpretation, by my own words. The fact that this wasn't even
brought as an option was an oversight, but doesn't change the fact that the
timeline RFC doesn't mention anything about voting, but about lining up
RFCs. Again, I don't pretend to remember what I meant when I wrote it - but
I would say that if I intended for it to be related to voting - whether it's
voting begins or voting ends - I would have likely wrote that explicitly in
the RFC, instead of using the lax 'line up' term.
If anybody is being political, it's people who try to use the timeline RFC -
designed to get PHP 7 out the door as soon as possible - while in parallel
denying a competing RFC to go to a vote on technicalities ("it's not the
same RFC"), to be discussed at all due to other technicalities ("you missed
the deadline!"), and at the same time suggest that there are "voting
irregularities", incidentally, among the people voting against their RFC.
Anthony, in case you don't know, that is politics. Not putting an RFC to
a vote.
Zeev
-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Sunday, March 15, 2015 9:11 PM
To: Zeev Suraski
Cc: Pádraic Brady; PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesZeev,
-----Original Message-----
From: Pádraic Brady [mailto:padraic.brady@gmail.com]
Sent: Sunday, March 15, 2015 9:00 PM
To: Zeev Suraski
Cc: Bob Weinand; PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesBob,
Thanks for the update. This time, though, although I completely
respect your decision not to put your RFC into a vote unless the
Dual STH mode fails, I'd like to either (with your permission) take
over the RFC or propose my own copy and move it to voting as soon
as allowed. This, under a commitment that if I see that Basic STH
is failing to garner a clear majority, I'll retract it and move to
support the Dual STH RFC instead for the sake of unity.No one individual has the right to break the existing rules around
voting.
There has been more than sufficient time to date to rewrite the
voting rules, debate voting rights, extend PHP7's deadline, or
propose the basic RFC so described. A vote in contravention of the
voting rules at the last possible minute cannot, by definition, be
recognised at this time. I wouldn't even vote since it might lend it
an air of ill deserved legitimacy, forgetting for a moment whether a
few PEAR contributions make me any more deserving of a vote than
others.No rule is being broken.
The PHP 7 timeline RFC (wiki.php.net/rfc/php7timeline) states the
following:
Line up any remaining RFCs that target PHP 7.0. | Now - Mar 15
(4+
additional months)As Bob pointed out, what 'Line up' means - whether it means vote ends,
vote begins, or discussion begins - is completely open to
interpretation. I don't remember what I meant when I wrote it, but
arguably, 'line up' is a lot closer to 'start discussing' than 'finish
voting', and as is typically the case when something is unclear, the
most lax interpretation is acceptable.By your own words: http://marc.info/?l=php-
internals&m=142451267910615&w=2Following Adam's analysis of the timeline, taking the more 'strict' (no
pun
intended!) interpretation of the timeline RFC, we still have until
tomorrow to
start the discussion and still target it for 7.0, no? Given the
importance of
this topic, I'd go for the more lax interpretation that allows for votes
to
begin by March 15, giving us all a bit more time to discuss.votes to begin by March 15. That was the interpretation you used a
month ago.Anthony,
I did not read my own words and therefore didn't notice an even more lax
interpretation was possible. What you can see is that I always lean
towards
the lax interpretation, by my own words. The fact that this wasn't even
brought as an option was an oversight, but doesn't change the fact that the
timeline RFC doesn't mention anything about voting, but about lining up
RFCs. Again, I don't pretend to remember what I meant when I wrote it -
but
I would say that if I intended for it to be related to voting - whether
it's
voting begins or voting ends - I would have likely wrote that explicitly in
the RFC, instead of using the lax 'line up' term.
Sorry, but ... even though your original RFC was very unclear about this,
everybody went by the "all votes must start by the 15th" interpretation
that has been discussed in that thread. Do you think it's an accident that
a whopping six RFC votes started today? It isn't.
Please don't start reinterpreting things to fit your needs. I am personally
totally fine with extending the PHP 7 timeline by say one month - but if we
do that, let's make it official and applying to everyone, not just some
particular RFC. I know for sure that there are a number of additional RFCs
that would have been submitted for PHP 7 had anyone known that it'll be
allowed.
Nikita
Sorry, but ... even though your original RFC was very unclear about this,
everybody went by the "all votes must start by the 15th" interpretation
that
has been discussed in that thread. Do you think it's an accident that a
whopping six RFC votes started today? It isn't.Please don't start reinterpreting things to fit your needs. I am
personally
totally fine with extending the PHP 7 timeline by say one month - but if
we do
that, let's make it official and applying to everyone, not just some
particular
RFC. I know for sure that there are a number of additional RFCs that would
have been submitted for PHP 7 had anyone known that it'll be allowed.
First off, this is Bob's interpretation which he brought up on Friday. Yes,
ideally I would have read the original text during the discussion period and
commented on it, but I didn't. I think the 3 month period for
implementation (that's mostly done) and testing gives a very reasonable time
period to absorb the most lax of interpretations.
I think it would be a shame to delay the timeline for this, but I also think
it would be a shame for the timeline - that was clearly not designed to
create de-facto bias towards one RFC or the other - to do exactly that.
Even if we were to push the timeline out by a bit, how do we do it? An RFC
with a minimum discussion period of two weeks and another week for a vote?
That kind of defeats the purpose. A gentlemen's agreement? Something else?
Zeev
Sorry, but ... even though your original RFC was very unclear about this,
everybody went by the "all votes must start by the 15th" interpretation
that
has been discussed in that thread. Do you think it's an accident that a
whopping six RFC votes started today? It isn't.Please don't start reinterpreting things to fit your needs. I am
personally
totally fine with extending the PHP 7 timeline by say one month - but if
we do
that, let's make it official and applying to everyone, not just some
particular
RFC. I know for sure that there are a number of additional RFCs that would
have been submitted for PHP 7 had anyone known that it'll be allowed.First off, this is Bob's interpretation which he brought up on Friday. Yes,
ideally I would have read the original text during the discussion period and
commented on it, but I didn't. I think the 3 month period for
implementation (that's mostly done) and testing gives a very reasonable time
period to absorb the most lax of interpretations.I think it would be a shame to delay the timeline for this, but I also think
it would be a shame for the timeline - that was clearly not designed to
create de-facto bias towards one RFC or the other - to do exactly that.Even if we were to push the timeline out by a bit, how do we do it? An RFC
with a minimum discussion period of two weeks and another week for a vote?
That kind of defeats the purpose. A gentlemen's agreement? Something else?Zeev
--
"Even if we were to push the timeline out by a bit, how do we do it?"
This is ~"My approach hasn't won yet, and instead of conceding default
due to democracy in action, I would like to change the process.
I am not insulting you. I am not attacking you. But this is some
bizarre stuff that is more than sneaky, and you really need to stop.
One RFC has won. Another RFC has lost. A third RFC is a backup plan
and nothing more.
Let the winning RFC win and lets get on with something else, because
today is the feature freeze and you don't get to manipulate that to
suit your own needs just because you want to.
-----Original Message-----
From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
Sent: Sunday, March 15, 2015 10:33 PM
To: Zeev Suraski
Cc: Nikita Popov; PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesSorry, but ... even though your original RFC was very unclear about
this, everybody went by the "all votes must start by the 15th"
interpretation that has been discussed in that thread. Do you think
it's an accident that a whopping six RFC votes started today? It
isn't.Please don't start reinterpreting things to fit your needs. I am
personally totally fine with extending the PHP 7 timeline by say one
month - but if we do that, let's make it official and applying to
everyone, not just some particular RFC. I know for sure that there
are a number of additional RFCs that would have been submitted for
PHP 7 had anyone known that it'll be allowed.First off, this is Bob's interpretation which he brought up on Friday.
Yes, ideally I would have read the original text during the discussion
period and commented on it, but I didn't. I think the 3 month period
for implementation (that's mostly done) and testing gives a very
reasonable time period to absorb the most lax of interpretations.I think it would be a shame to delay the timeline for this, but I also
think it would be a shame for the timeline - that was clearly not
designed to create de-facto bias towards one RFC or the other - to do
exactly that.Even if we were to push the timeline out by a bit, how do we do it?
An RFC with a minimum discussion period of two weeks and another week
for a vote?
That kind of defeats the purpose. A gentlemen's agreement? Something
else?Zeev
--
To unsubscribe,
visit: http://www.php.net/unsub.php"Even if we were to push the timeline out by a bit, how do we do it?"
This is ~"My approach hasn't won yet, and instead of conceding default due
to democracy in action, I would like to change the process.I am not insulting you. I am not attacking you. But this is some bizarre
stuff
that is more than sneaky, and you really need to stop.
Phil,
Do you mind STOPPING TO TWIST THINGS TO FIT YOUR AGENDA, please? And no,
saying you don't insult me or attack me after doing exactly that does not
change anything.
It's NIKITA that proposed this. It's BOB that proposed the lax (and very
reasonable) interpretation to the Mar 15 timeline. Why did you not 'not
insult' and 'not attack' them? Is it open season on Zeev only?
One RFC has won. Another RFC has lost. A third RFC is a backup plan and
nothing more.
None won and none lost as of yet. Are there some special rules for a backup
plan anywhere in the Voting RFC or the Timeline RFC that I missed? Or are
you allowed to make those up? How sneaky of you. And bizarre. But no
worries, I'm not insulting or attacking you!
THIS is toxic. If Nikita brings up a point, I ask him to elaborate a bit,
and you jump on me (as you did numerous times over the last month) - this is
unacceptable.
Zeev
-----Original Message-----
From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
Sent: Sunday, March 15, 2015 10:33 PM
To: Zeev Suraski
Cc: Nikita Popov; PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesSorry, but ... even though your original RFC was very unclear about
this, everybody went by the "all votes must start by the 15th"
interpretation that has been discussed in that thread. Do you think
it's an accident that a whopping six RFC votes started today? It
isn't.Please don't start reinterpreting things to fit your needs. I am
personally totally fine with extending the PHP 7 timeline by say one
month - but if we do that, let's make it official and applying to
everyone, not just some particular RFC. I know for sure that there
are a number of additional RFCs that would have been submitted for
PHP 7 had anyone known that it'll be allowed.First off, this is Bob's interpretation which he brought up on Friday.
Yes, ideally I would have read the original text during the discussion
period and commented on it, but I didn't. I think the 3 month period
for implementation (that's mostly done) and testing gives a very
reasonable time period to absorb the most lax of interpretations.I think it would be a shame to delay the timeline for this, but I also
think it would be a shame for the timeline - that was clearly not
designed to create de-facto bias towards one RFC or the other - to do
exactly that.Even if we were to push the timeline out by a bit, how do we do it?
An RFC with a minimum discussion period of two weeks and another week
for a vote?
That kind of defeats the purpose. A gentlemen's agreement? Something
else?Zeev
--
To unsubscribe,
visit: http://www.php.net/unsub.php"Even if we were to push the timeline out by a bit, how do we do it?"
This is ~"My approach hasn't won yet, and instead of conceding default due
to democracy in action, I would like to change the process.I am not insulting you. I am not attacking you. But this is some bizarre
stuff
that is more than sneaky, and you really need to stop.Phil,
Do you mind STOPPING TO TWIST THINGS TO FIT YOUR AGENDA, please? And no,
saying you don't insult me or attack me after doing exactly that does not
change anything.It's NIKITA that proposed this. It's BOB that proposed the lax (and very
reasonable) interpretation to the Mar 15 timeline. Why did you not 'not
insult' and 'not attack' them? Is it open season on Zeev only?One RFC has won. Another RFC has lost. A third RFC is a backup plan and
nothing more.None won and none lost as of yet. Are there some special rules for a backup
plan anywhere in the Voting RFC or the Timeline RFC that I missed? Or are
you allowed to make those up? How sneaky of you. And bizarre. But no
worries, I'm not insulting or attacking you!THIS is toxic. If Nikita brings up a point, I ask him to elaborate a bit,
and you jump on me (as you did numerous times over the last month) - this is
unacceptable.Zeev
I am sorry for hurting your feelings but you are being manipulative
and I am not a fan of that. I have no agenda, I just want to see you
put an end to this weird rule bending, definition changing, rule
ignoring "convenient" interpretations of policies that stop Dual STH
going through by any means possible.
Are there some special rules for a backup
plan anywhere in the Voting RFC or the Timeline RFC that I missed?
Yeah Bob specifically said it would go to vote if Dual STH failed, so
that makes it a backup plan. :)
I am sorry for hurting your feelings but you are being manipulative
and I am not a fan of that. I have no agenda, I just want to see you
put an end to this weird rule bending, definition changing, rule
ignoring "convenient" interpretations of policies that stop Dual STH
going through by any means possible.Are there some special rules for a backup
plan anywhere in the Voting RFC or the Timeline RFC that I missed?Yeah Bob specifically said it would go to vote if Dual STH failed, so
that makes it a backup plan. :)--
Hello,
if Zeev didn't want to make Dual STH go through by any means possible,
he could have just retracted his RFC few hours ago when the Dual STH
wasn't passing, effectively ending both RFCs as not passing, given I
understand the voting process correctly. (Sure, it would be a textbook
example of a so-called "dick move", but that's not the point.)
If you realize this (in combination with the statement that if
everything else fails, he'll go with the Dual one, even if he
disagrees with it, so the end users at least have SOME type hints in
PHP 7.0), then you'll probably see all the attempts to bring another
competing RFC as an honest attempt at making the language better by
bringing another look on STHs to vote on, and not as pushing some
agenda.
Or at least that's my point of view.
Regards
Pavel Kouril
-----Original Message-----
From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
Sent: Sunday, March 15, 2015 11:12 PM
To: Zeev Suraski
Cc: PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar TypesAre there some special rules for a backup
plan anywhere in the Voting RFC or the Timeline RFC that I missed?Yeah Bob specifically said it would go to vote if Dual STH failed, so
that makes it a backup plan. :)
You're answering an unknown question I didn't ask.
I asked whether there was anything in the Voting RFC
(wiki.php.net/rfc/voting) or the Timeline RFC
(wiki.php.net/rfc/php7timeline), the two RFCs being used to block a Basic
STH poll from going to a vote for PHP 7.0, that somehow make it legitimate
for it to be proposed if the Dual Mode RFC fails.
The answer - there's not.
Zeev
I asked whether there was anything in the Voting RFC
(wiki.php.net/rfc/voting) or the Timeline RFC
(wiki.php.net/rfc/php7timeline), the two RFCs being used to block a Basic
STH poll from going to a vote for PHP 7.0, that somehow make it legitimate
for it to be proposed if the Dual Mode RFC fails.The answer - there's not.
I may be missing something, but isn't the reason why its not going up for
vote that it
has not gone through the RFC process yet? 2 weeks here, 2 weeks there and
such?
Honest question, please don't take it off-tone.
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://www.amsterdamphp.nl <http://wwwamsterdamphp.nl
I don't think agreeing to any of the three proposals out there is the
best option. I personally think there are viable options out there
that have not yet been heavily discussed.
For instance, everyone and their dog has complained about PHP's overly
promiscuous type juggling. This is one reason scalar types proposals
are having issues; we don't want to have the same promiscuous type
juggling on these scalar types so we are defining new rules. Instead,
why don't we fix at least some of those conversions first?
Hi Zeev,
No rule is being broken.
Your re-interpretation seems extremely lax, very timely, and out of
kilter with previous interpretations discussed on this list in getting
all RFCs into vote by today. It was also not the rule I was referring
to, so your statement isn't actually directed at my email. I'll wait
and see what the RFC announcement brings, however, since that is the
only thing of relevance in seeing whether my own concerns are
addressed or not.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com