Building a better PHP together. View as Markdown

If it tries to create a legitimate connection and form an opinion (in this
case, the fact that almost all engine maintainers oppose a patch that's
about to be forced on them) - there's absolutely nothing wrong with it.

There is a lot wrong about that.

Numerous critical features have been vetoed, rejected or blocked
(before or after RFCs) because Zend so called maintainers considered
them useless. Let take an example, annotation, interestingly enough
every major frameworks out there use some userland implementation
which implements exactly what the RFC proposed.

Being crazy about performance is a good thing, being disconnected from
user needs is another, as well as heavily opposed to additions or
improvements without even taking care about anything but performance
(even when proven wrong in the recent case) is counter productive, at
best.

Anyway, my point is that 99% of the political issues we are facing is
because of the lack of communication and hidden/private development.
It is always a bad thing. It was bad last year for opcache, it is bad
now for phpng, even if the outcome is a very good thing in the long
run. The result is a good thing, the way it is achieved hurts PHP in
many ways. This is something you should work on, or think about it, as
one the company leaders.

To make my point clear, I have absolutely no personal issue against
you or Zend. But we have to understand that Zend is not alone, since
long, to take care about PHP's future. We should find better ways to
cooperate, early, often, efficiently instead of letting such things
happen again.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

Here are some behaviors that are inappropriate:

• Asking members of the list to vote in a particular way

There's actually nothing wrong with that. I absolutely don't think
this should become a rule or a guideline.

I disagree. We should not have rallying cries on the list asking
people with no connection or opinion on something to vote a certain
way. That is unacceptable behaviour.

It's a lot better to rally for your cause out in the open than in
private discussions in the back of IRC. It's a lot more transparent, at
least to see where people stand.

I agree that rallying your cause on list is okay, it just needs to be
appropriate. Let me provide an example of something that I think is
appropriate:

"I will be voting yes/no on ... because ... and encourage everyone to
vote with this in mind"

I think the heated and unhelpful debate on the "A call for help
(urgent)" is evidence enough to validate the stance of not asking
members to vote in a particular way.

-----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