Re: Re: [RFC] Facility for QA reports

On Wed, Dec 05, 2001 at 06:56:46PM +0100, Tobias Schenck wrote : > I had a look at the tables which are quite nice and I read the proposal > which I think is great. I wondered whether it would be useful to include the > PHP-version and or snapshot-version in at least the testrun-table. For > performance-reasons it could also be included in the testresults table. Indeed, this information is the most important and has been forgotten in the DB layout (thats why it is only a draft). I think putting this in the testrun table makes most sense. A textual field representing the PHP version number. Either 'php -v' or 'php -m' (the latter also exposes the Zend Engine version number) and proper format this with sed/grep/fsck. > I think of simply quering SELECT snapshotversion FROM testresults WHERE > testcase_id = 12345 AND result = "failed" and similar statements. This might > make it easier to track down the commit that fixed or caused the bug. I'm iffy on this. Someone who thinks he knows it better may speak up. > > I am neither member of the QA-team or the DEV-team, so I don't know, if this > would actually help. I just thought it might be worth mentioning. This has nothing to do with it. Everyone interested in it is invited to participate. I'm neither in the QA team and wouldn't really consider myself being in the dev team just because I occasionally throw patches into it. > > Kind regards and thanks for all the work on PHP, > > Tobias Schenck > > "Markus Fischer" <mfischer@guru.josefine.at> schrieb im Newsbeitrag > news:20011205122905.A30955@guru.josefine.at... > > # > > # Table structure for table 'testrun' > > # > > # Practically, this is the table which glues together > > # everything. A combination of a user with his > > # os,version,distribution runs his configure command and all > > # testresults are identified with this testrun.id (and also > > # their respective testcase) > > > > DROP TABLE IF EXISTS testrun; > > CREATE TABLE testrun ( > > id smallint(5) unsigned default NULL auto_increment, > > user_id smallint(5) unsigned NOT NULL, > > os_id smallint(5) unsigned NOT NULL, > > os_version_id smallint(5) unsigned NOT NULL, > > distribution_id smallint(5) unsigned NOT NULL, > > configure_id smallint(5) unsigned NOT NULL, php_version char(80) not null, With the PHP and Zend version nicely formatted so we can run a DISTINCT select on thiss table and so the user can choose the filter on the query page. Other ideas? > > > > PRIMARY KEY (id) > > ) TYPE=MyISAM; > > > > # > > # Table structure for table 'testresults' > > # > > # The information we actually want. result is either > > # 'failed', 'passed' or 'skipped'. I also see the > > # possibility of using a SET but found it less flexible. The > > # remark is actually a generated output (optionally) by the > > # testscript matching the testcase. > > # > > # The 'bug' field contains a comma separator list of > > # associated bug report numbers for this particular > > # testresult if and only IF it has failed. They're used to > > # build the links from the QA reports to the bug database. It > > # is not yet decided how this should be properly handled. > > > > DROP TABLE IF EXISTS testresults; > > CREATE TABLE testresults ( > > id smallint(5) unsigned NOT NULL default '0', > > testrun_id smallint(5) unsigned NOT NULL, > > testcase_id smallint(5) unsigned NOT NULL, > > result char(80) NOT NULL, > > remark char(80) NOT NULL default '', > > bugs text NOT NULL default '', > > > > PRIMARY KEY (id) > > ) TYPE=MyISAM; - Markus -- Please always Cc to me when replying to me on the lists.