Hello Pierre, Wednesday, July 30, 2008, 9:33:10 AM, you wrote:
> Hi, > On Wed, Jul 30, 2008 at 9:18 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> So you are saying that PHP can use GD in a way that makes it brake which is >> not covered by GD's testing? > That's not what I'm saying. First, GD in php is not the same library > that you have in libgd.org and is better integrated with php (not > possible to do so using an external library). Secondly, almost all > tests available in libgd's tests suite have been ported or are in the > process to be ported to php. >> Sounds very bad, actually having GD a PHP >> project makes it a really special case. > It is irrelevant in this case, they are not the same. >> So if you want to and can find a >> good way of integrating GD testing than I am happy to address that. > It is the case already. >> Unless >> you deliver a solution that goes for our goal which is 90% required for >> green in the near future I however have to exclude it. > As I agree that good coverage is a noble cause. I prefer to have a > slightly lower visible coverage and get the code actually covered > marked as such. Please revert this change for GD. So it appears that gd is in the exact same situation as ext/dba/libcdb which I explicitly ported for PHP. Now that one has 82.1% coverage so obviously has no larger non PHP chunks and also seems to be triggered in quite enough ways. So I didn't pull it. My intention was to drop libs that hopefully have there own testing infrastructure and don't get fully triggered by PHP testing. Best example is pcre. Where it simply doesn't make sense to write phpt tests that trigger all those edge cases from PHP. So we rather exclude that from our calculations as we don't even have the intention to test those. Best regards, Marcus -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
