Re: 64-bit SGI account offer

On November 1, 2002 11:31 am, Melvyn Sopacua wrote: > 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). The particular problem that I see, is that certain tests require nearly an imposible setup for them to run (mysql/pgsql) tests. As such those tests as nice as they are, are useless. I am suggesting we consider removing those tests all together from our test suit. > 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. dl() will fail in multi-threaded enviroment with E_ERROR so it is not a reliable mechanism. If a user does not have an extension avaliable for use to us, we should not try to load it for testing perpouses. As far as we are concerned, that extension is not avaliable. > > 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. -1 on this idea. Ilia