Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83180
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.179 as permitted sender)
MIME-Version: 1.0
Date: Thu, 19 Feb 2015 08:24:21 -0500
Message-ID: <CAAyV7nHHBxSPemoF0Gj+ridov99WFLMh-+nxDwBY5ikJwV0OUg@mail.gmail.com>
To: francois@php.net
Cc: Lester Caine <lester@lsces.co.uk>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Using Other Channels (was Scalar Type Declarations v0.5)
From: ircmaxell@gmail.com (Anthony Ferrara)

Francois

On Thu, Feb 19, 2015 at 6:58 AM, Fran=C3=A7ois Laupretre <francois@php.net>=
 wrote:
>> De : Lester Caine [mailto:lester@lsces.co.uk]
>>
>> On 19/02/15 04:44, Dennis Birkholz wrote:
>> > I just saw the reddit where you mention that v0.4 is practically
>> > abandoned now, so I will just renounce my previous mail!
>>
>> DO NOT USE OTHER CHANNELS!
>
> Agreed.

You mean like contacting another contributor in private asking them to
not make a proposal and to stop work on it?

> And the RFC was not abandoned at all. I and others have been working almo=
st continuously on a 'compromise' single-mode approach during the last 3 da=
ys (and nights), as activity on the list shows with no doubt. So,  pretendi=
ng the RFC to be 'abandoned' is just a way to discard a disagreed work.

Let me quote something that was said:

"Ze'ev and Fran=C3=A7ois have not-so-politely asked [Sara] to not put 0.4
forward since they have something they believe they have consensus
on."

So while it may not have been "abandoned", it was sandbagged
(sabotaged, strong-armed, etc). I used abandoned as a light term to
not point out to list what strong-arming happened behind the scenes.
But since you apparently don't want "other channels used"...

I can't stress how deplorable that act is. How harmful to the
community it is to ask in private for a contributor to stop what they
are doing because someone else "has a better idea". We had a proposal
that *had* consensus (66%). It was withdrawn. With some minor changes,
at least 25% of no-voters would have changed their mind (based on
conversations around why the voted no).

So rather than go for the 70-75% consensus that we **know** we have,
we should drop all work for a magic vaporware proposal. Contributors
should stand down and not contribute because "you know better".

I'm sorry, I favor the proposal that's in writing and implemented
rather than one that's yet to be seen. If yours does indeed prove to
be as good as possible, then the votes will decide. Or if it convinces
me early enough, I'll withdraw the current proposal. But based on
everything I've seen in the discussion threads, I can't possibly see
how that will happen. I hope you surprise me, but in case that you
don't, I'm moving forward with the existing implementation that we
know has support.

> As long as she does not officially gives up (posting to the list), I'll k=
eep considering Sara still has the lead on scalar type hinting. If she offi=
cially gives up, I'll immediately propose to take it over and, if we are se=
veral to want it, we'll discuss.

I created a forked RFC. You can keep her as lead all you want, that
doesn't mean I can't move forward with my RFC.

> That's the rule and I encourage list members to explicitly show their sup=
port to the formal process we all agreed upon.

What rule is that? Can you point me to anywhere in the Voting RFC that
says that? https://wiki.php.net/rfc/voting

It doesn't.

That's fine. Let's let the votes decide rather than relying on strongarming=
.

> For the rest, Lester summarized quite well my view about designing PHP fo=
r static analysis, instead of static analysis for PHP ;)

Saying a problem doesn't exist doesn't make it go away.

Anthony