I agree, and I’m not suggesting we ignore it; I just pointed out it makes
no sense that such a drastic low-level change will be forced on those who
effectively maintain the low-level engine for all of us. I don’t have a
magical solution on how to solve it at this point.
I did suggest two solutions to the situations within the current voting
process:
1. Clearly expressing the concerns Dmitry has about this patch in the
Performance section, so that at least people know what’s on the table; And
add another option – the option – the one that has the true userland
implications (the parts related to IS_LONG), and mention clearly that this
one will come with no meaningful performance (memory/CPU) drawbacks.
2. If the authors of the RFC object (which is within their right, of
course) – appealing to voters to vote ‘no’ on this one, and create another
RFC for the IS_LONG parts.
Zeev
Even though that I agree, that our current voting process is suboptimal,
but I would rather see it fixed instead of ignoring the rules when it is
inconvenient/plain wrong.
What I do think is wrong with the current rfc, is that it states that it
needs only 50%+1 of the votes for acceptance.
The patch is big, it will affect every php installation (eg. not just some
platforms), it changes the Zend Engine, and it requires some non-trivial
effort from the extensions to support it, so even though that the direct
impact on the userland isn't that big (code with long strings etc. which
would fatal will now starts working, big numbers will overflow differently,
etc.) I think it still mandates a 66%+1 vote.
Just my 2 cents.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu