|
|
| (29 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| This is the checklist for QA to follow when releasing Genome Browser tracks. | | This page is no longer maintained. |
| General rule: stop testing when you come to the first non-trivial error, and bounce the track to the B queue until the track sponsor fixes it.
| |
| Friendly advice: There is a script, '''qaThis.csh''', that will do many of the checks for you (and can be and should be expanded to do more)
| |
| | |
| ==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. For complex tracks, look for genomewiki pages on it, and/or look through the push queue for previous problems encountered on similar tracks. Familiarize yourself with the tables and files needed for this track.
| |
| | |
| ==Push to hgwbeta==
| |
| | |
| (If this is an update to an to an existing track, you may want to hold off on this step so that you can compare old and new tracks on hgwdev and hgwbeta.)
| |
| | |
| Push all tables from hgwdev to hgwbeta. There are two ways:
| |
| | |
| sudo mypush $db $table mysqlbeta
| |
| | |
| or, for a list of tables:
| |
| | |
| bigPush.csh $db $tableListFile
| |
| | |
| [[ThreeStateTrackDb | make beta]] on hgwbeta in kent/src/hg/makeDb/trackDb like so:
| |
| | |
| make beta DBS=$db
| |
| | |
| Request a push of all supporting files in /gbdb from hgwdev to hgnfs1. Note that hgwbeta and the RR share the files on hgnfs1, so once these files are in place, there is not another push required when the track is released to the RR.
| |
| | |
| ==Makedoc==
| |
| | |
| Look for an entry for your track in src/hg/makeDb/doc/$db.txt. If there is no mention of this track, make a request to the track sponsor. Basic tracks that are loaded automatically with a new assembly may only have a tiny reference in the makedoc. UCSC Genes has its own document.
| |
| | |
| ==Release Log and URL==
| |
| | |
| The "Release Log" field in the push queue should generally contain the shortLabel of the track, or a short description of what is being released if it does not make sense to put a shortLabel here. The entry in this field will be added to the auto-generated [http://genome.ucsc.edu/goldenPath/releaseLog.html release log page]. If it makes sense to link to the hgTrackUi page for this track, make an entry in the "Release Log URL" field like so:
| |
| | |
| ../../cgi-bin/hgTrackUi?db=[DATABASE]&g=[TRACK]
| |
| An actual example:
| |
| ../../cgi-bin/hgTrackUi?db=hg19&g=affyU133
| |
| | |
| ==Index==
| |
| | |
| Press "show sizes" in the push queue and check to see that all tables have at least one index key. This is especially important for large tables. There are some tables that do not need an index, such as tables that only have a single line that point to the location of a BAM file.
| |
| | |
| Note that you can also check indices in MySQL using the command "show index from".
| |
| | |
| ==Tables are sorted and internally consistent==
| |
| | |
| Run any of these that apply to your tables:
| |
| | |
| * genePredCheck
| |
| | |
| Checks that tables in the [http://genome.ucsc.edu/FAQ/FAQformat.html#format9 genePred format] are valid.
| |
| | |
| * pslCheck
| |
| | |
| Checks that [http://genome.ucsc.edu/FAQ/FAQformat.html#format2 psl] tables are valid.
| |
| | |
| *checkTableCoords
| |
| | |
| Checks that the genomic coordinates in positional tables are legal (e.g., coordinates are not off the end of a chromosome).
| |
| | |
| * positionalTblCheck
| |
| | |
| Checks to see that the a positional table is ordered by chrom and chromStart. 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
| |
| | |
| Alert the track sponsor if there is an error. He/she may determine that the items are sorted enough to be released. (As long as the items are almost all in order, it will not affect performance.) Also note that Genbank tables are not expected to be in order after updates have run.
| |
| | |
| ==joinerCheck==
| |
| | |
| Look in src/hg/makeDb/schema/all.joiner for references to your tables and grab the identifiers associated with those tables. Then, for each identifier, run joinerCheck like so:
| |
| | |
| joinerCheck -keys -identifier=$identifier -database=$db all.joiner
| |
| | |
| If there are errors or the table is not mentioned in all.joiner, notify the track sponsor. An entry in the tablesIgnored section of all.joiner is sufficient if there are no table relationships to check.
| |
| | |
| Be aware of this [[All.joiner_problem | problem with joinerCheck]]. Basically, if you get output that looks like this:
| |
| | |
| Checking keys on database hg18
| |
| | |
| that is NOT followed by lines like this:
| |
| | |
| anoCar1.blastHg18KG.qName - hits 45332 of 45332 ok
| |
| | |
| then the rule didn't really run, and you need to remove the -database parameter.
| |
| | |
| You can also run joinercheck with the -times flag:
| |
| | |
| joinerCheck -times -database=$db all.joiner
| |
| | |
| Look for any errors that are relevant to your track.
| |
| | |
| The runJoiner.csh script is a shortcut for all of the above, but beware that wildcards in tablesIgnored sections are not recognized, and if the problem above occurs, then you need to run joinerCheck directly.
| |
| | |
| ==Chromosome coverage==
| |
| | |
| Some tracks don't have data on all chromosomes. To check which ones do have data:
| |
| | |
| countPerChrom.csh $db $table
| |
| | |
| Look for chromosomes with no data that should have data. If a "regular" chrom (not random or haplotype) has no data, a note like this should appear in place of the track drop-down:
| |
| | |
| [No data-chr21]
| |
| | |
| This is controlled by the "chromosomes" setting in trackDb.ra. The chromosomes line in trackDb.ra specifies the chromosomes that DO have data. This line is the same as the "restrictList" field in the trackDb table.
| |
| | |
| Alternatively, there are some easy graphical ways to check chromosome coverage:
| |
| | |
| * Import the table into Genome Graphs.
| |
| | |
| * 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.
| |
| | |
| ==FeatureBits and Gaps==
| |
| | |
| Run featureBits, or use the runBits.csh script to run featureBits. runBits.csh checks for coverage and overlap with gap, and also checks for undbridged gaps. Alert the track sponsor if there are unbridged gaps and this is a track created at UCSC. Put featureBits results in the push queue. If previous assembly also has this track, compare featureBits between current assembly and previous assembly -- if there are big differences between the old and new tracks, alert the track sponsor.
| |
| | |
| ==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, as 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. It can be run on a single database like this:
| |
| | |
| checkHgFindSpec -checkTermRegex $db
| |
| | |
| There is also a cron job that runs it on all of the active databases on hgwdev and puts the results here (look for your $db.$table combination):
| |
| | |
| http://genecats.cse.ucsc.edu/qa/test-results/checkHgFindSpec/hgwdevOutput
| |
| | |
| If checkHgFindSpec gives errors pertinent to your track, request that the track sponsor edit the search entry in trackDb.ra.
| |
| | |
| ==Track description==
| |
| | |
| Read the track description and edit for clarity, spelling, and grammar.
| |
| | |
| Ensure references are in the correct [[CBSE_citation_format | format]] and in alphabetical order (by first author listed). Ensure quotes, ampersands, and less than and greater than signs are represented with their [[http://www.ascii.cl/htmlcodes.htm html names]].
| |
| | |
| 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 from the mysql table. Check all details for this data point, including all links. Make sure information from the table is displaying correctly (e.g., if a color is used in the table, make sure that color appears for the item.)
| |
| | |
| ==Protein sequence check (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 a similar track if possible. Look to see that the features in your track are more or less in the same position as similar tracks. Look for a lot of items that have a chromStart or chromEnd that is one position different from existing tracks. This could indicate an off-by-one error in the new track.
| |
| | |
| ==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 aesthetically pleasing and scientifically interesting.
| |
| | |
| ==Performance and Display==
| |
| | |
| 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.
| |
| | |
| 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.
| |
| | |
| Hit the Reverse button and ensure your track displays correctly.
| |
| | |
| ==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].
| |
| | |
| Brooke pushes the tableDescriptions tables to the RR once a week.
| |
| | |
| ==Label lengths==
| |
| | |
| Check that the shortLabel is 17 characters or less and that the longLabel is 80 characters or less.
| |
| | |
| ==Push Request==
| |
| | |
| When the track is ready to be released, ask admins (push-request at soe) for a push of the tables (including trackDb_public and hgFindSpec_public, if needed) from mysqlbeta to mysqlrr. Push any associated downloads. Notify (cc:) the track sponsor on the push request.
| |
| | |
| If the track already exists on the RR you may need to selectively push the tables/trackDb. Click [[Replacing_old_tables_with_new_ones | here]] for more information.
| |
| | |
| ==Validate on the RR==
| |
| | |
| Check your track on the RR. Check that searches work (if not, you probably need to push the hgFindSpec_public table). Also check that all default tracks still display. If you filled in the "Release Log URL" field in the push queue, check the next day to be sure that the link from the [http://genome.ucsc.edu/goldenPath/releaseLog.html release log] works as expected.
| |
| | |
| [[Category:Browser_QA]][[Category:Browser QA tracks]]
| |
