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

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

    The branch name must use the following naming convention:

    review-xxx-YYY-very_short_desc

    PartDescription
    xxximplementor initials, in lower case
    YYYJIRA bug number, with DFDL prefix removed
    desca short description (optiona)

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

    Also note that the description has been left off in the examples for brevity.
     

  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

    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 read A Note About Git Commit Messages for the correct commit message format. 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.

    Additionally, tests should be created during this process to convince yourself that your changes are correct. These tests should be placed in the "src/test/scala-new" directory.
     

  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

        

  10. Implementor prepares bug for Review, performing the following tasks:

    1. Create new comment containing requirement ID's

    2. Choose "Review Solution", placing JIRA bug "In Review"

    3. Assign JIRA bug 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

    4. 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
    $ 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
    $ 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
    $ git branch -D review-sdl-123 

        

  20. Implementor chooses "Review Accepted" in JIRA bug, adds commit ID in comments, and assigns to TL