RE: [PHP-DEV] Building a better PHP together.

From: Date: Mon, 19 May 2014 11:06:04 +0000
Subject: RE: [PHP-DEV] Building a better PHP together.
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-74356@lists.php.net to get a copy of this message
> -----Original Message-----
> From: Zeev Suraski [mailto:zeev@zend.com]
> Sent: 17 May 2014 21:42
> To: Ferenc Kovacs
> Cc: Levi Morrison; internals
> Subject: RE: [PHP-DEV] Building a better PHP together.
>
> I think it is ok to rally people for voting or making them aware
> that
> something will go through which they probably don't want to, and
> also ok to
> reconsider based and giving them reasons.
>
> But I think that prominent people like you should refrain from
> asking
> people to vote no while providing only generic/blanket statments
> ("morally
> wrong", etc.) because you are in a position where some people will
> just
> blindly follow what you say, and we should vote purely on the base
> on the
> technical merit of the proposed rfc, and not based on which sides
> has the
> more prominent people supporting it.
>
>
>
> I wish that were true but the numbers prove otherwise J
>
>
>
> Regardless, my ‘call for help’ was very much in context (even if
> terse), it
> wasn’t a ‘vote No because I say so’.  It also followed a long online
> debate
> on internals@ where I expressed my opinion very clearly.
>
> I’d agree that ‘Vote X and get $500’, ‘Vote Y for a spot in heaven’,
> or
> ‘Vote Z because I say so’ are no-no’s.

I hope you will forgive the opinionated ramblings of a normally
dedicated lurker (although I've made sporadic contributions to The
Fine Manual, I've done no development on the c sources -- so I don't
have much voice here).

First of all, let me say I'm glad to see this debate seems to have
calmed down to some sort of consensus and looks like producing the
best possible result for PHP as a whole. HOWEVER:

(1) The intemperate and bullying nature of the original "Please Help:
Vote No" email made me immediately want to vote "Yes" just to punish
such untoward behaviour. (I wouldn't otherwise have considered voting
at all, because I actually don't care -- not having any code that is
ever likely to handle such big numbers/arrays/whatever.) Fortunately,
I read all the ensuing arguments, now feel I have a much better
understanding of the scope of the patch, and would actually be more
inclined to vote No for the RFC *as it stands*.

(2) It seems to me that the emerging consensus is different enough
from the RFC currently up for vote that it should be withdrawn,
redrafted on the basis of (say) Nikita's proposal, and go through
another round of debating and vote. After all, as has been pointed
out, it's likely to be 2 or 3 months before phpng is far enough
developed to be capable of accepting any 64-bit patch, so withdrawing
and redrafting is not likely to lead to any time penalty.

(3) On the subject of required majority and what "language change"
actually means -- my interpretation is that this is definitely a
language change. AIUI, the patch could cause PHP integers to change
from 32 to 64 bits for some users -- and whilst this shouldn't matter
in the vast majority of cases, it *is* a change to how PHP works for
them.

(4) I do think the phpng team probably should have been a bit more
pro-active in making their project known -- even a small announcement
just to let people know it existed and might cause conflicts with e.g.
int64 might have prevented the huge conflagration we've just seen! To
have worked on it for so long with no outside awareness, particularly
in view of the int64 patch, strikes me as distinctly disrespectful.

(5) Finally, let me say that I admire the dedication of the two teams
who have been working hard on such fundamental changes to the engine
-- but, from my point of view, the total dedication of some team
members to their project's target has been part of the problem. It
looks to me that, though there are very fine cases to be made on both
sides, neither one should necessarily be accepted in full and each
side should make some compromise -- and the exact nature of those
compromises should be the focus of the next round of (civilised!)
debate.

Thanks for listening -- I hope I haven't offended anyone too much
(or, at least, equally all round :).

Cheers!

Mike

--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
403a Leslie Silver Building, City Campus, Leeds Metropolitan University,
Woodhouse Lane, LEEDS,  LS1 3ES,  United Kingdom
E: m.ford@leedsmet.ac.uk     T: +44 113 812 4730
(on 22nd September, Leeds Metropolitan University will become Leeds Beckett University)





From 22 September 2014 Leeds Metropolitan University will become Leeds Beckett University.
Find out more at http://www.leedsbeckett.ac.uk
To view the terms under which this email is distributed, please go to:-
http://www.leedsmet.ac.uk/email-disclaimer.htm


Thread (15 messages)

« previous php.internals (#74356) next »