Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84858
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <d29a6faab8dd07ce62f6df153c400b03@mail.gmail.com>
References: <BLU436-SMTP63B4758D2D902644C6BB24E2050@phx.gbl>
	<d29a6faab8dd07ce62f6df153c400b03@mail.gmail.com>
Date: Sun, 15 Mar 2015 18:51:39 +0100
Message-ID: <CAB6YZuyzE0AWjzYvH02RNDXYP3036j+t_uTzwx=5m2eStCGhKA@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

On Sun, Mar 15, 2015 at 5:55 PM, Zeev Suraski <zeev@zend.com> wrote:
> 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 Types
>>
>> 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
>> --
>> PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit:
>> http://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To 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