All,
In case there's any chance people lost track in the noise:
Please, please - vote No on https://wiki.php.net/rfc/size_t_and_int64_next#vote
We're in an unprecedented situation where almost all of the code
contributors to the engine are against a patch that is being forced on
them for no reason, negates months of hard work performed to get us
phpng, and is somehow enjoying a majority (almost exclusively from
people who are not engine contributors).
I urge everyone with a right to vote (and only those, as per
https://wiki.php.net/rfc/voting) to vote no, and even those who voted
yes to revert their votes to no.
We need your help!
Regards,
Zeev
All,
In case there's any chance people lost track in the noise:
Please, please - vote No on
https://wiki.php.net/rfc/size_t_and_int64_next#voteWe're in an unprecedented situation where almost all of the code
contributors to the engine are against a patch that is being forced on them
for no reason, negates months of hard work performed to get us phpng, and
is somehow enjoying a majority (almost exclusively from people who are not
engine contributors).I urge everyone with a right to vote (and only those, as per
https://wiki.php.net/rfc/voting) to vote no, and even those who voted
yes to revert their votes to no.We need your help!
Am i watching a CNN movie?
Cheers
Anatol
No, you're watching the Voting RFC going haywire.
It's the second time we have an RFC that deals with internal
implementation as opposed to features and functions, something the RFC
process was never designed to do. And it appears to be failing, much
like it almost failed the last time around.
Last time it happened I raised the hope that non-engine contributors
will refrain from placing votes on such RFCs, we may need to (try and)
formalize it.
Zeev
All,
In case there's any chance people lost track in the noise:
Please, please - vote No on
https://wiki.php.net/rfc/size_t_and_int64_next#voteWe're in an unprecedented situation where almost all of the code
contributors to the engine are against a patch that is being forced on them
for no reason, negates months of hard work performed to get us phpng, and
is somehow enjoying a majority (almost exclusively from people who are not
engine contributors).I urge everyone with a right to vote (and only those, as per
https://wiki.php.net/rfc/voting) to vote no, and even those who voted
yes to revert their votes to no.We need your help!
Am i watching a CNN movie?Cheers
Anatol
No, you're watching the Voting RFC going haywire.
It's the second time we have an RFC that deals with internal
implementation as opposed to features and functions, something the RFC
process was never designed to do. And it appears to be failing, much like
it almost failed the last time around.Last time it happened I raised the hope that non-engine contributors
will refrain from placing votes on such RFCs, we may need to (try and)
formalize it.Zeev
All,
In case there's any chance people lost track in the noise:
Please, please - vote No on
https://wiki.php.net/rfc/size_t_and_int64_next#voteWe're in an unprecedented situation where almost all of the code
contributors to the engine are against a patch that is being forced on
them for no reason, negates months of hard work performed to get us
phpng, and is somehow enjoying a majority (almost exclusively from
people who are not engine contributors).I urge everyone with a right to vote (and only those, as per
https://wiki.php.net/rfc/voting) to vote no, and even those who voted
yes to revert their votes to no.We need your help!
Am i watching a CNN movie?
Cheers
Anatol
Exactly, the single thing I see failing here is the voting RFC. Not
because of itself, but because it's useless when it comes to the politics
we have here. And that confrontations do actually much more harm than any
technical issue ever.
Regards
Anatol
All,
In case there's any chance people lost track in the noise:
Please, please - vote No on https://wiki.php.net/rfc/size_t_and_int64_next#vote
We're in an unprecedented situation where almost all of the code
contributors to the engine are against a patch that is being forced on
them for no reason, negates months of hard work performed to get us
phpng, and is somehow enjoying a majority (almost exclusively from
people who are not engine contributors).
Have you really written "negates months of hard work"? I mean, really? :)
--
Pierre
@pierrejoye | http://www.libgd.org
Please, please - vote No on https://wiki.php.net/rfc/size_t_and_int64_next#vote
Everyone, please vote yes. The No side is unlikely to lose, due to the 2/3 majority required. The Yes side does need a lot of help to win, though. Remember, every no vote requires 2 yes votes to counteract it.
We're in an unprecedented situation where almost all of the code
contributors to the engine are against a patch that is being forced on
them for no reason, negates months of hard work performed to get us
phpng, and is somehow enjoying a majority (almost exclusively from
people who are not engine contributors).
It negates months of hard work performed behind closed doors in secret (phpng), compared to lots of hard work done in the open (64-bit patch).
I urge everyone with a right to vote (and only those, as per
https://wiki.php.net/rfc/voting) to vote no, and even those who voted
yes to revert their votes to no.
No way. Let’s use the right types for the job. ‘int’ and ‘long’ should never be used for sizes of data structures.
It’s not as if 64-bit will kill phpng, it’ll just delay it.
Andrea Faulds
http://ajf.me/
Everyone, please vote yes. The No side is unlikely to lose, due to the 2/3
majority required. The Yes side does need a lot of help to win, though.
Remember, every no vote requires 2 yes votes to counteract it.
That has nothing to do with the fact applying this patch is morally wrong,
and also may or may not be true.
It negates months of hard work performed behind closed doors in secret
(phpng), compared to lots of hard work done in the open (64-bit patch).
Unlike phpng, this is a tactical patch that while changes a lot of code, is
mostly about "dirty work" than research.
Have you used PHP 3? Then maybe 4? Surely 5?
All were developed in exactly the same way. First a working PoC was
established, after lots of trial and error and hard work it was shared with
everyone to join in.
Spinning phpng's work as something evil is as ridiculous as it is wrong.
Sabotaging it because of it is even worse.
No way. Let’s use the right types for the job. ‘int’ and ‘long’ should
never be used for sizes of data structures.
This is ridiculous. But I'm sure you know a lot better than Andi, Derick,
Dmitry, Nikita, Rasmus, Stas, Xinchen and myself. I fail to understand who
in his rift mins thinks it's both technically and morally legitimate to
force this patch on this group.
It’s not as if 64-bit will kill phpng, it’ll just delay it.
You don't seem to realize what's going on here. It won't delay it, it'll
greatly slow it down, and given phpng is all about performance - it negates
its goals. Phpng's key performance gain had to do with compacting it's
data structures. This goes in the opposite direction, 180 degrees.
There's no way to fix it later as some suggest, it's an inherent
incompatibility in directions.
For the current PHP it yields an 8% memory increase. For phpng it'll be a
lot more since it's data structures are more compact and therefore it'll be
a lot more, relatively speaking.
Zeev
Everyone, please vote yes. The No side is unlikely to lose, due to the 2/3 majority required. The Yes side does need a lot of help to win, though. Remember, every no vote requires 2 yes votes to counteract it.
That has nothing to do with the fact applying this patch is morally wrong, and also may or may not be true.
Morally wrong? I don’t see how morals come into this. Yes, it would undo some work that has been done by you, in favour of someone else’s work. But I don’t see what’s ‘wrong’ about that.
Spinning phpng's work as something evil is as ridiculous as it is wrong. Sabotaging it because of it is even worse.
I never said phpng was evil. I said it was developed behind closed doors.
You, on the other hand, just said that the 64-bit patch is evil ("applying this patch is morally wrong”). Two can play at this game.
“Spinning the 64-bit patch as something evil is as ridiculous as it is wrong.”
You don't seem to realize what's going on here. It won't delay it, it'll greatly slow it down, and given phpng is all about performance - it negates its goals. Phpng's key performance gain had to do with compacting it's data structures. This goes in the opposite direction, 180 degrees. There's no way to fix it later as some suggest, it's an inherent incompatibility in directions.
For the current PHP it yields an 8% memory increase. For phpng it'll be a lot more since it's data structures are more compact and therefore it'll be a lot more, relatively speaking.
Relatively, yes. In absolute terms, however, what is the gap between vanilla and phpng + 64bit patch?
--
Andrea Faulds
http://ajf.me/
That has nothing to do with the fact applying this patch is morally wrong, and also may or may not be true.
Morally wrong? I don’t see how morals come into this. Yes, it would undo some work that has been done by you, in favour of someone else’s work. But I don’t see what’s ‘wrong’ about that.
Between the list of names I wrote, you have 80-90% of the engine code
if not more. The yes group is - for the most part - comprised of non
engine contributors, which are forcing their will on the ones who are.
I'm not saying these guys aren't PHP contributors, btw. But much
like I wouldn't dream of telling the docs team how they should do
their job, I don't expect the opposite to happen either.
I never said phpng was evil. I said it was developed behind closed doors.
You suggested it was somehow inferior because of that, not just stating a fact.
For the current PHP it yields an 8% memory increase. For phpng it'll be a lot more since it's data structures are more compact and therefore it'll be a lot more, relatively speaking.
Relatively, yes. In absolute terms, however, what is the gap between vanilla and phpng + 64bit patch?
We don't have any numbers about phpng plus the patch because it
doesn't yet exist. My guess is that it'll be in the 20-30% range to
add this patch to phpng. Comparing to vanilla doesn't make sense at
all - we didn't work phpng to waste the gains on this patch - but to
improve performance.
Zeev
Le 17 mai 2014 à 18:03, Zeev Suraski zeev@zend.com a écrit :
But much
like I wouldn't dream of telling the docs team how they should do
their job, I don't expect the opposite to happen either.
So if I understand you suggest that only core developers should decide for core modifications ? Isn’t it against the voting RFC which you’re one of the authors ?
That’s a really weird vision of an open source community for me.
-----Original Message-----
From: bruno@chalopin.fr [mailto:bruno@chalopin.fr]
Sent: Saturday, May 17, 2014 9:31 PM
To: PHP internals
Subject: Re: [PHP-DEV] A call for help (urgent)Le 17 mai 2014 à 18:03, Zeev Suraski zeev@zend.com a écrit :
But much
like I wouldn't dream of telling the docs team how they should do
their job, I don't expect the opposite to happen either.So if I understand you suggest that only core developers should decide
for core
modifications ? Isn’t it against the voting RFC which you’re one of the
authors ?
It may be against what’s written there (which is why I need to beg as
opposed to just point people to it) - but not its spirit.
The voting RFC was written with language functions, features and processes
in mind. Not implementation. Things like Traits - which most certainly
involves Core, or return type hinting - these are the things the Voting
RFC was created for. As you pointed out, I'm one who those who wrote much
of the text of it, I should know.
I didn't even dream that we'll have RFCs that deal with low-level
implementation up for vote. If I did, there'd be a separate dedicated
section for it.
That’s a really weird vision of an open source community for me.
It actually isn't. Open Source is typically some form of meritocracy, and
those who have merit in a given component are those who own it. The RFC
process was designed to give a wider range of 'stakeholders' a say in the
language direction - and I think it greatly helped PHP in the last few
years. However it was never designed to give those stakeholders a say
about its implementation. Unfortunately, I wasn't sufficiently
forward-looking to make that clear in the RFC. I still think this can
work without changes to the Voting RFC, again, assuming people do not vote
on implementation RFCs that don't directly concern the parts of the code
they own.
Zeev
That has nothing to do with the fact applying this patch is morally wrong,
and also may or may not be true.
Morally wrong? But doing months of Dev in secret while knowing that we work
on the same area is morally awesome?
Unlike phpng, this is a tactical patch that while changes a lot of code,
is
mostly about "dirty work" than research.
A hack over a hack remains a hack. With all respects to the authors and
what they achieved so far.
Spinning phpng's work as something evil is as ridiculous as it is wrong.
Who said that?
Sabotaging it because of it is even worse.
Excuse me?
You don't seem to realize what's going on here. It won't delay it, it'll
greatly slow it down, and given phpng is all about performance - it
negates
This is again wrong. It is not slow but a small memory usage increase. It
is even actually faster with the 64bit patch in many cases (based on
5.6+patch, phpng+patch coming as soon as I am done with making it portable).
For the current PHP it yields an 8% memory increase.
Wrong again. We show 4% increase.