Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

  1. Jira bug is created, status is "Open"

  2. Jira bug is assigned to implementor

  3. Implementor "Starts Progress" in Jira bug

  4. Implementor creates a new bug branch with the following naming convention: review-xxx-YYY-very_short_desc

    xxx = your initials
    YYY = Jira bug number
    very_short_desc is an optional description of the bug

    Note that the Jira bug number is mandatory. This means all changes must have an associated Jira bug.

    $ git fetch origin
    $ git checkout -b review-sdl-123-foo origin/master

     

  5. Implementor performs all development in bug branch, this includes repeating the following steps many times until you are ready for review:

    $ edit files
    $ git add ...
    $ git commit
    $ git fetch origin
    $ git rebase origin/master
    $ sbt test
    $ git push --force origin review-sdl-123-foo

    Notice the frequent commits and pushes. This is a great way to ensure we do not accidentally lose commits. But be careful when using the --force option, as that will replace whatever branch is on the server.

    Also, please see the following link about the commit message format:

    http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

    Please follow those standards, with the additional requirement that the last line should contain only the Jira bug number preceded by an empty line, e.g. "\nDFDL-123". If there are more than one bug related to the commit, separate them with commas.

  6. When finished developing, implementor ensures changes work with the latest upstream

    $ git fetch origin
    $ git rebase origin/master
    $ sbt test

     

  7. Implementor squashes commits into a reasonable patchset.

    $ git rebase -i origin/master

    Please pay attention to commit message format

  8. Implementor ensures all tests pass

    $ sbt test

     

  9. Implementor pushes to ncsa opensource servers for review

    $ git push --force origin review-sdl-123-foo

     

  10. Implementor "Reviews Solution" in Jira bug, placing bug "In Review" and assigns to SE

  11. SE creates review in Crucible and assigns to reviewer

  12. SE assigns Jira bug to reviewer, adding Crucible ID to the comments

  13. Reviewer reviews patchset. If changes are necessary:


    1. Reviewer assigns Jira bug back to implementor, adding a comment that changes are necessary

    2. Implementor makes changes to bug branch according to comments (following steps 5-9)

    3. If necessary, implementor pushes bug branch back to ncsa for re-review and assigns Jira bug back to reviewer. Repeat review process as necessary. Note, if changes are simple enough, re-review is not always necessary. Use your own judgment

  14. Reviewer assigns Jira bug back to implementor, commenting that it is good to push

  15. Implementor ensures changes work with the latest upstream

    $ git checkout review-sdl-123-foo
    $ git fetch origin
    $ git rebase origin/master

     

  16. Implementor squashes review changes into a reasonable patchset

    $ git rebase -i origin/master

     

  17. Implementor ensures all tests pass

    $ sbt test
     
  18. Implementor sets master branch to bug branch and pushes

    $ git checkout master
    $ git reset --hard review-sdl-123-foo
    $ git push origin # do not use the --force option here

     

  19. Implementor deletes bug branch (both remote and local)

    $ git push --delete origin review-sdl-123-foo
    $ git branch -D review-sdl-123-foo
     
  20. Implementor chooses "Review Accepted" in Jira bug, adds commit ID in comments, and assigns to TL

  • No labels