Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84857
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.86 as permitted sender)
Message-ID: <BLU436-SMTP143F089828132E26A4D03EBE2050@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <d29a6faab8dd07ce62f6df153c400b03@mail.gmail.com>
Date: Sun, 15 Mar 2015 18:51:03 +0100
CC: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <BLU436-SMTP63B4758D2D902644C6BB24E2050@phx.gbl> <d29a6faab8dd07ce62f6df153c400b03@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
From: bobwei9@hotmail.com (Bob Weinand)


> Am 15.03.2015 um 17:55 schrieb Zeev Suraski <zeev@zend.com>:
>=20
> Bob,
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Zeev
>=20
>=20
>=20
>> -----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 Types
>>=20
>> Hey, to clarify what the way to go with this RFC is.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> But, in any case this RFC will go to vote on the 24th if Anthonys RFC
> couldn't
>> gather a 2/3 supermajority.
>>=20
>> Thanks,
>> Bob

Please do not top post...

Zeev,
=20
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.
=20
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.
=20
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.
=20
You had a time to do this RFC, but you did coercive. Now, it's my move =
with this RFC and not yours.
=20
Please accept that and don't play against us.
=20
Thanks,
Bob=