|
|
| (47 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| This is the checklist for QA to follow when checking releasing tracks. General rule: Stop testing when you come to the first non-trivial error, and mark the track on-hold in the queue until the track sponsor fixes it. | | This page is no longer maintained. |
| | |
| | |
| ==Background familiarity==
| |
| | |
| If you haven't worked with a track like this one, and it already exists on the RR for another assembly, use it a bit on the RR to become familar with it.
| |
| | |
| ==Push to hgwbeta==
| |
| | |
| Push all tables to hgwbeta. Note sizes. Make [[ThreeStateTrackDb | beta]] on hgwbeta in kent/src/hg/makeDb/trackDb like so:
| |
| | |
| make beta DBS=hg18
| |
| | |
| Push all supporting files from /gbdb to hgnfs1. If these files are large (greater than 2G), be sure to ask the pushers to add these files to the mirror site 'exclude' list at hgdownload:/etc/rsyncd.conf .
| |
| | |
| ==Makedocs==
| |
| | |
| Review the contents of the corresponding src/hg/makeDb/doc/{build}.txt. If the contents are missing, make that request to the track sponsor.
| |
| | |
| ==Track description==
| |
| | |
| Confirm that the information for your track exists and is correct. If not, make this request to the track sponsor and stop checking.
| |
| | |
| ==Contact information sanitized==
| |
| | |
| Make sure that any email addresses given on the details page have been through Hiram's sanitizer (encodeEmail.pl). It turns the address into an encrypted HREF "mailto:" address that makes it harder for spammers to use.
| |
| | |
| ==All details: 1 data point==
| |
| | |
| Choose a representative data point for the track. Check all details for this data point, including all links. If the track includes DNA and proteins, check a few random translations.
| |
| | |
| ==Display==
| |
| | |
| Turn on to full display mode a track that is located physically below your track in the display. Make sure that when your track is in full display mode, that the items in the track below it are still mapping correctly. Sometimes There can be an off-by-one error which is caused by your track. If this is happening, you should not push your track.
| |
| | |
| ==Gene annotations only==
| |
| | |
| Choose a gene that is on the positive strand, exonCount of 1. Check that the protein sequence displayed by the details page matches the sequence displayed by the Base Position track.
| |
| | |
| ==Comparison==
| |
| | |
| Compare your track to Known Genes. Look for alignment of exons.
| |
| | |
| ==Default Position==
| |
| | |
| Re-evaluate the default position. Does the new track appear as a default? Should it? Location (dbDb.defaultPos) & track priorities (trackDb.ra) should be optimized to make available annotation esthetically pleasing and scientifically interesting.
| |
| | |
| ==Gaps==
| |
| | |
| Compare your track to Gap. Zoom out 10x until 100 million bases or full chrom. Use dense mode as necessary. Perform for a sampling of chromosomes. Look for large areas of missing data. Allow for "gene-desert" regions.
| |
| | |
| ==FeatureBits==
| |
| | |
| Run featureBits, or use the runBits.csh script to run featureBits. The script will also check the track items for overlap with undbridged gaps (which is bad, but permissible in some cases -- check with the developer if you are not sure). Put results in pushQ entry. If previous assembly also has this track, compare featureBits between current assembly and previous assembly.
| |
| | |
| Can also use getYield.csh if comparing to refGene:cds.
| |
| | |
| ==Performance==
| |
| | |
| For tracks displayed by default, the full chromosome view (chr1) should display within 20 seconds. For tracks which are not displayed by default, the full chromosome view should display within a minute. Update qa/test-results/perf/display.html. Use JKSQL_PROF=on to measure SQL time (reported in Apache error log).
| |
| | |
| ==Check that tables are sorted and internally consistent==
| |
| | |
| *checkTableCoords
| |
| | |
| For positional tables, checks that the genomic coordinates are legal (e.g., coordinates are not off the end of a chromosome).
| |
| | |
| * positionalTblCheck
| |
| | |
| For any positional table, check to see that the table is ordered by chrom and chromStart. The utility positionalTblCheck does this. A positional table being out of order can cause a huge slowdown in display speed. If the table passes there will be no output. If the table does not pass there will be an error message like: "table hg18.snp129 not sorted starting at row 4867: chr1:387005"
| |
| Note that it is not important that the items be sorted exactly in order - as long as the items are almost all in order, it will not affect performance.
| |
| | |
| * genePredCheck/pslCheck
| |
| | |
| For gene prediction tracks (with tables in the [http://genome.ucsc.edu/FAQ/FAQformat.html#format9 genePred format], run genePredCheck (run the command with no arguments for instructions). For [http://genome.ucsc.edu/FAQ/FAQformat.html#format2 psl] tables, run pslCheck.
| |
| | |
| ==Index==
| |
| | |
| Check the indices for the primary table using the mySQL command "show index from ". Expect to find chrom/chromStart and chrom/chromEnd. Press show sizes in the push queue and look at the indexes. Make sure no tables are missing and all return valid values.
| |
| | |
| ==Searching==
| |
| | |
| If the track item names are relatively unique, perform a few searches. If search isn't enabled, make that request to the track sponsor. This isn't required for the push. If the track item names are relatively similar (i.e. RNA Genes, TFBS) we don't want to enable search, it would return too many matches.
| |
| | |
| The checkHgFindSpec tool with the -checkTermRegex option will check that all of the names in a table that is searched match the regular expression specified in trackDb.ra. There is not an option to run it on a single table, so just run it on the whole database and look for output specific to your table. For instance:
| |
| | |
| checkHgFindSpec -checkTermRegex hg19
| |
| | |
| If this gives errors pertinent to your track, request that the track sponsor edit the search entry in trackDb.ra.
| |
| | |
| ==joinerCheck==
| |
| | |
| Time permitting, ask the track sponsor about applicable rules in all.joiner for your track and run joinerCheck -identifier -database -keys. You can also use Bob's runJoiner.csh.
| |
| | |
| ==Chromosome coverage==
| |
| | |
| Some tracks don't have data on all chromosomes. To check which ones do have data:
| |
| countPerChrom.csh db table
| |
| and/or:
| |
| countPerChrom.csh db table histogram
| |
| OR: SELECT DISTINCT chrom FROM encode_UVA_DNARep_0_2;
| |
| If a "regular" chrom (not random or haplotype) is missing data, it should NOT be listed in the trackDb restrictList setting. You you can check the restrictList in trackDb as follows:
| |
| SELECT tableName, restrictList FROM trackDb WHERE tableName like 'encode_UVA_DNARep%';
| |
| restrictList (if not blank) should be a comma-separated list of chroms with data. In trackDb.ra, the chromosomes line specifies the contents that later becomes restrictList after doing a "make strict" on beta. e.g. chromosomes chr2, chr4, chr5.
| |
| | |
| EASY GRAPHICAL WAYS TO CHECK COVERAGE: (1) Import the table into Genome Graphs. (2) To see a count plus a histogram of chrom coverage, select the table in the Table Browser, hit the "describe table schema" button, and click the "values" link for the chrom field.
| |
| | |
| In addition, you can use the countPerChrom.csh script to get a count of track items for each chromosome, and checkCoverage.csh, to get a list of the largest blocks of non-annotated regions (with links) that are not gaps.
| |
| | |
| ==Track Settings (hgTrackUi)==
| |
| | |
| Click on the track name or the mini-button to the left of the track (in hgTracks) to get to the track settings page. Make sure that the track settings work as expected.
| |
| | |
| ==Table Descriptions==
| |
| | |
| Hit the "view table schema" button (on hgTrackUi, hgc, or hgTables) and make sure there is a description column present with descriptions of the table fields. If a track has more than one table, be sure to check for table descriptions on each of them. The description column uses the 'tableDescriptions' table to display this information. This table is built nightly on hgwdev and hgwbeta, and must be pushed to the RR if it contains descriptions for a new type of table (things like psl will already be out there).
| |
| | |
| Background on the tableDescriptions table is [http://genomewiki.ucsc.edu/index.php/AutoSql here].
| |
| | |
| ==Release Log==
| |
| | |
| Remember that the contents of the "release log" field in the qaPushQ will be added to the auto-generated release log page.
| |
| | |
| ==trackDb and hgFindSpec==
| |
| | |
| Check whether trackDb needs to be pushed to the RR (use table browser on RR). Check that no rows would get deleted when pushing trackDb. Check whether other rows get added. If so, update the pushqueue for that, or, temporarily delete the row, push trackDb, then regenerate it on hgwbeta.
| |
| Can use compareTrackDbs.csh hgwbeta hgw1 hg16
| |
| Can use compareHgFindSpecs.csh hgwbeta hgw1 hg16
| |
| (will create 2 output temp files in current directory per assembly checked)
| |
| | |
| ==push request==
| |
| | |
| Ask admins (push-request at soe) for a push of the table (incl trackDb, if needed) to the RR.
| |
| Notify (cc:) the track submitter on the push request, in case they are not on the browser-qa alias.
| |
| | |
| Be sure to ask the pushers to 'unexclude' any of the hgnfs1 files that need to be available for the track to work for the mirror sites.
| |
| | |
| ==Validate on the RR==
| |
| | |
| Check your track on the RR. Also check that all default tracks still display.
| |
