Re: 64-bit SGI account offer

At 17:04 1-11-2002, Ilia A. wrote:

On November 1, 2002 10:51 am, Sebastian Nohn wrote:

-----Original Message----- From: Ilia A. [mailto:ilia@prohost.org] Sent: Friday, November 01, 2002 4:26 PM To: Sebastian Nohn; PHP Quality Assurance Team Mailing List Subject: Re: [PHP-QA] 64-bit SGI account offer

Disagree. It's just a verification. You can also more easy see when something broke on a certain machine with a certain configuration. This evening im going to take a look at the make-tests.php

Well, there are only 3 possible test result states, FAILED,PASS or SKIP. If the test did not succeed we know it passed or was skipped for whatever reason. For the purposes of debugging I believe that data is for the most part meaning less.

I would rather suggest to leave the "skip"-thing. Why? The answer is easy: With my way, we would KNOW that PHP runs on for example Tru64 with Oracle 8.1.7 but not on Linux with 8.1.9. With your way we only would know that it does'nt work on Linux 8.1.9. If a test did not fail, we know it worked or was skipped. Considering our current test suit comprises of some 362 tests and growing sending huge amounts of information, which for the most part is useless would be counter productive.

Yep - get your point. [...]

P.S. We currently have some 30-40 tests mysql/pgsql that are always skipped, simply because those tests require an un-restricted, passwordless connection to the database server. This is not the case on 99.99% of the systems, perhaps we should reconsider the usefulness of those tests?

Which is my point. We're now working in 'reasons' for skips in all tests. This isn't the way I intended it, when I proposed it. If an extension is not available, don't bother. If something doesn't work (ie: locale support) add the reason. If you compile a list of extensions which we're skipped for a reason, then the 'skip' output would be much smaller and useful as well (ie: ask the user to identify the locale string for his/her platform). And the other one, is dl(). We should either force the modules directory (providing this will work accross platforms) or warn the user about the untested extensions, by providing a list of '--enable-foo=shared,/path/to/foo' compiled extensions, to the testsuite. Thirdly - I know people don't like to use configure args, for other things than making the extension work, but for databases I can truly see the advantages of: --with-db-test-user= --with-db-test-db= --with-db-test-host= We can do with these three (maybe --with-db-test-port= if some db's handle them funny) and map that in the tests themselves. I don't think there's a db extension, that can't make a connection and do the tests, when this information is provided. If we add a 'you provided --with-db-test-*. Please make sure blabla' at the end of configure - people are alerted to the possibility as well. Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua