Code summary: Difference between revisions

From Genecats
Jump to navigationJump to search
(Links changed from .soe or .cse to .gi)
(Undo revision 4737 by Daniel (talk))
 
Line 6: Line 6:
This email is for folks who commit code changes to our git repository.
This email is for folks who commit code changes to our git repository.


One of the things I do every three weeks (in conjunction with the final build) is to create the code summaries from the preceding 3 weeks of check-ins as seen [http://genecats.gi.ucsc.edu/builds/versions.html here] and [http://genomewiki.gi.ucsc.edu/index.php/Genome_Browser_Software_Features here].
One of the things I do every three weeks (in conjunction with the final build) is to create the code summaries from the preceding 3 weeks of check-ins as seen [http://genecats.cse.ucsc.edu/builds/versions.html here] and [http://genomewiki.cse.ucsc.edu/index.php/Genome_Browser_Software_Features here].


It takes me about 4-6 hours to puzzle through the sometimes-(but-not-always!)-cryptic commit messages and come up with the list. To help make this a more reasonable task for me, I am asking each of you, by way of this email, to summarize your own commits. I will then combine your summaries and post.
It takes me about 4-6 hours to puzzle through the sometimes-(but-not-always!)-cryptic commit messages and come up with the list. To help make this a more reasonable task for me, I am asking each of you, by way of this email, to summarize your own commits. I will then combine your summaries and post.
Line 15: Line 15:
e.g. "Turned on Assembly Name by default in Base Position Track. #4073"
e.g. "Turned on Assembly Name by default in Base Position Track. #4073"


Please follow the language and level of detail in my [http://genecats.gi.ucsc.edu/builds/versions.html previous] summaries.
Please follow the language and level of detail in my [http://genecats.cse.ucsc.edu/builds/versions.html previous] summaries.


When you are trying to determine exactly what's important (and high-level) enough to be included in the summary, remember what these summaries are used for:
When you are trying to determine exactly what's important (and high-level) enough to be included in the summary, remember what these summaries are used for:

Latest revision as of 16:55, 29 August 2018

If you have committed code to the shared /kent git repository during a code cycle, you will be expected to provide a summary of those changes to the project manager. Immediately following the final build, you will receive an email listing your commits for the past 3 weeks. The following email explains how to craft and submit your code summaries to the project manager:


Hello Git Commit Fanatics,

This email is for folks who commit code changes to our git repository.

One of the things I do every three weeks (in conjunction with the final build) is to create the code summaries from the preceding 3 weeks of check-ins as seen here and here.

It takes me about 4-6 hours to puzzle through the sometimes-(but-not-always!)-cryptic commit messages and come up with the list. To help make this a more reasonable task for me, I am asking each of you, by way of this email, to summarize your own commits. I will then combine your summaries and post.

Your individual code summaries are due to me every third Tuesday following the Final Build by 5pm. If you don't want the pressure of having to churn them out on one particular day, consider writing them up before the build (or keeping a list as you go).

Include summaries of changes to both software (internal, external, bug fixes, new features) and data (tracks, assemblies). And please also include the redmine number associated with each of your summary sentences. e.g. "Turned on Assembly Name by default in Base Position Track. #4073"

Please follow the language and level of detail in my previous summaries.

When you are trying to determine exactly what's important (and high-level) enough to be included in the summary, remember what these summaries are used for:

  • mirror sites (to determine if they want/need to upgrade)
  • users (to see what cool new features to explore)
  • QA (to know what to test before CGIs go out)
  • grant progress report writers & annual NAR authors
  • your own annual self-evaluation report!

Remember to summarize all three weeks of check-ins:

  • Branch - Day 16
  • Design/Review2 Branch - Day 9
  • Design/Review - Day 2

If you checked in anything during the three weeks of the build cycle, you will automatically receive an email from the Build Meister. That is your cue to forward that email to me with your summaries included.

If you are a QAer you can ignore the automatic email from the Build Meister.

Thanks in advance for your help on this. The number of commits is just getting a bit too unwieldy for me to continue this task on my own.