Push-Request Etiquette: Difference between revisions
From Genecats
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| Line 26: | Line 26: | ||
*** For example, it is better to send several small push requests, than to lump multiple different table/assembly push requests into one email (even if all the pushes are related to the same goal). | *** For example, it is better to send several small push requests, than to lump multiple different table/assembly push requests into one email (even if all the pushes are related to the same goal). | ||
*** In essence, if your push request looks very complicated, stop and think about redrafting it. | *** In essence, if your push request looks very complicated, stop and think about redrafting it. | ||
==Related pages== | |||
[[New_track_checklist]] [[ThreeStateTrackDb]] [[Pushing_trackDb]] | |||
[[Category:Browser_QA]][[Category:Browser QA tracks]][[Category:FAQ]] [[Category:Browser_Staff_Training]] [[Category:Browser_QA_Training]] [[Category:Browser_QA_CGI]] | [[Category:Browser_QA]][[Category:Browser QA tracks]][[Category:FAQ]] [[Category:Browser_Staff_Training]] [[Category:Browser_QA_Training]] [[Category:Browser_QA_CGI]] | ||
Revision as of 21:01, 15 October 2020
Remember to check your path:
- A bad path will cause issues for cluster-admin
- do a list "ls /absolute/path/to/requestingPushOf/fileName" before requesting the push
- But not the path to your source tree Not: /cluster/home/yourLogin/kent/src/hg/htdocs/...
Remember to do your QA on beta
- Beta exists for you to check data before release to the RR
- This means checking your track and data work properly on beta.
- This means you'll have to sudo mypush $db $table mysqlbeta
- This means you'll have to sudo gbdbPush and gbdb data.
- This means you can't request a push of tables/data from beta unless you've put things on beta.
- Let people know you are doing a make public on hg19/hg38 mm9/mm10 (most used assemblies)
Remember to check after your push request that your data arrived on the RR (world).
- Don't leave users to check your push, check your push to catch unexpected errors.
- This is the final QA check, to see your data arrived safely to the RR and works properly
- Do not just request the push and then forget about it; we need to check the push went through and did not unintentionally break something (or didn't make it).
- If requesting/pushing hg.conf changes, keep in mind they are instantaneous but can be reversed by asking cluster-admin to undo what you just requested.
Be kind to the cluster-admin
- Make things as easy as possible for cluster-admin
- Don't expect them to respond immediately to your push-requests
- Make sure your requests are proper before making them: CORRECT PATH; TABLES EXIST; GBDB EXIST
- AVOID a late push-request if it can wait until morning (i.e., 5pm Friday push-request, because you'll have to stick around to check it, and they might be heading out the door).
- Structure push requests so that they are easy to understand and straightforward to execute for cluster-admin:
- For example, it is better to send several small push requests, than to lump multiple different table/assembly push requests into one email (even if all the pushes are related to the same goal).
- In essence, if your push request looks very complicated, stop and think about redrafting it.
