Project

General

Profile

artdaq development workflow

All development for artdaq packages should follow this pattern:

  1. Create Issue detailing why work is being performed
  2. Determine branch name: Use gitflow-based branch names (feature/ bugfix/ working/) and Issue#_Description (i.e. feature/21145_SMEM_ChangesToTraces or support/21146_ReformatUsingClangFormat)
  3. Update artdaq repository branches wiki page
  4. git checkout develop;git checkout -b $branchName
  5. Make/test code changes
    1. All commit messages should include the issue number so that Redmine can associate them with the appropriate issue (i.e. "Reformat files using clang-format `find . -type f -name *.cc -o -name *.cpp -o -name *.h -o -name *.hh`. Part of Issue #21146"). (Note that Redmine recognizes the '#' character followed immediately by the issue number; "# 21146" or "Issue 21146" will not work)
    2. When issue has been resolved, change Issue state to "Resolved"
  6. Get another artdaq developer to validate (review) code changes
    1. Other developer (reviewer) should do git checkout $branchName;git merge develop
      • Do not rebase.
    2. if there are anything other than trivial conflicts, abort merge and talk to issue resolver
    3. relevant commits can been seen via:
      on_branch=`git status | awk '/^On branch/{print$3}'`;\
      git log develop..$on_branch --no-merges
      

      To look at the commits:
      for cc in `git log develop..$on_branch --no-merges | grep ^commit | awk '{print$2}'`;do
        git show $cc|cat
      done|less
      
    4. review should be done on this branch (with develop merged in)
  7. Reviewer should merge changes into develop via: git checkout develop; git merge $branchName; git push --all
    • If there are problems with the merge, abort the merge, checkout the branch and merge/resolve there (with help as appropriate) and re-review (i.e. goto 6).*
  8. Reviewer should update artdaq repository branches wiki page, filling in the review methods used and the date the develop merge was performed.
  9. Reviewer should mark the Issue as "Reviewed", and put their name in the "Co-Assignees" field
  10. During the next release, the release manager will perform the following steps for all reviewed branches:
    1. Associate the Issue with the release version
    2. Include the link to the Issue on the Release notes page, see Artdaq_Release_Notes_Pages
    3. Change the Issue to the "Closed" state
    4. Remove the branch from the repository (git push --delete <branch>) Note the final commit hash output by git
    5. Move the table line from artdaq repository branches to Branch Graveyard, including the hash from the previous step

Branches which have been merged into development and working branches which are no longer used will be cleaned up at release time, when related Issues are set to the "Closed" state.