Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95234 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84949 invoked from network); 16 Aug 2016 15:16:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Aug 2016 15:16:53 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.230 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.230 mail4-3.serversure.net Linux 2.6 Received: from [217.147.176.230] ([217.147.176.230:60765] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4D/86-36656-46E23B75 for ; Tue, 16 Aug 2016 11:16:52 -0400 Received: (qmail 25567 invoked by uid 89); 16 Aug 2016 15:16:49 -0000 Received: by simscan 1.3.1 ppid: 25561, pid: 25564, t: 0.0819s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 16 Aug 2016 15:16:49 -0000 To: internals@lists.php.net References: <53c8bb5d-3d60-6019-d089-93d0285bb8ff@lsces.co.uk> <982dfdae-5c44-5ffc-c3c6-66e361839a67@lsces.co.uk> Message-ID: <7ee557d1-1d8e-749f-2310-8a8e946e5270@lsces.co.uk> Date: Tue, 16 Aug 2016 16:16:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] orphan extensions cleanup From: lester@lsces.co.uk (Lester Caine) 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