ATTENTION!
This page is no longer being updated. It has moved to genomewiki.

QA Checklist for pushing a track that is not new

Last updated: August 14, 2009.
Author: Jim Kent and Heather Trumbower. Updated by Ann Zweig and Brooke Rhead
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.

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 strict on hgwbeta in kent/src/hg/makeDb/trackDb like so:

make strict 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).

Positional Table Sort

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.

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.

Help pages

(This may no longer be relevant as Donna does not maintain them manually anymore and the table-browser schema link in description page handles much of this now.)
The User Guide includes track descriptions at hgTracksHelp.html. Review the track description for correctness. Send edit requests to the person who maintains the static page content (currently Donna).

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.

genePredCheck/pslCheck

For gene prediction tracks (with tables in the genePred format, run genePredCheck (run the command with no arguments for instructions). For psl tables, run pslCheck.

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 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.

ATTENTION! This page is no longer being updated. It has moved to genomewiki.