On 16/08/16 15:55, Rowan Collins wrote: > I'm sure everyone agrees is that the ideal situation is *not* to drop > it, and instead to find someone willing to commit to maintain it. But > there's no point saying it's maintained if nobody is actually performing > that role.
While my name is not against maintaining it, that is what I have been doing since I first started using PHP. My problem is that despite having programmed in C/C++ since long before USING PHP, I find it very difficult to actually understand the C code that makes it up. I have no problems with the test side and we have a stable test suite for testing against outside of PHP but many of the 'changes' in the code base ARE generic changes to some core process and trying to mirror them into an unmaintained extension is the problem here. Only people who understand WHY they are making a change which affects every extension really know how to do that. Trying to work out the PHP7 changes without a deep understanding if what was needed was why *I* could not handle it ... and I'm sure other extension maintainers were in the same boat? http://php7.lsces.org.uk/ibtest.php tests what we want to do, and nothing there has changed since I first used it back in 2004 and the next step is to test with FB3 and PHP7 but I've not had time to set up a suitable target site as yet. Any firebird user knows the password to get in ... 'masterke' for those who don't ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
