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

Compare with Current View Page History

« Previous Version 31 Next »

Note: In the below steps, <version_branch> should be replaced with the version branch of Daffodil you are working on based on the Branch Workflow.

 

  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 --prune origin
$ git checkout -b review-sdl-123 --track origin/<version_branch>

    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 (optional)

    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 <files>
$ git commit
$ git fetch --prune origin
$ git rebase origin/<version_branch>
$ 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 is 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.

    If this is a bug fix ticket, any tests that were previously failing should be moved from scala-debug to scala-new.
     

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

    $ git fetch --prune origin
$ git rebase origin/<version_branch>
$ sbt test

        

  7. Implementor squashes commits into a reasonable patchset.

    $ git rebase -i origin/<version_branch>

    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 creates review in Crucible and assigns to reviewer

    1. Go to Daffodil Fisheye

    2. Click "Create Review"

    3. Select the "DFDL" project and click "Create Review"

    4. Click "Browse Changesets"

    5. Check the checkmarks next to your commits
       
    6. Click "Edit Details"

    7. Change the author and moderator to Implementor

    8. Add one or more reviewers

    9. Click "Done"

    10. Select "Start Review"

  11. Implementor prepares bug for review, performing the following tasks:

    1. Add comment to Jira issue containing requirement ID's met when implementing the Jira bug

    2. Add Crucible review ID to the comments

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

  12. Reviewer reviews patchset. If changes are necessary:


    1. Reviewer annotates Crucible review with comments

    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

    4. Repeat review process as necessary. Note, if changes are simple enough, re-review is not always necessary. Use your own judgment
          
  13. Implementor closes review by selecting "Tools > Close"

  14. Implementor ensures changes work with the latest upstream

    $ git checkout review-sdl-123
$ git fetch --prune origin
$ git rebase origin/<version_branch>

        

  15. Implementor squashes review changes into a reasonable patchset

    $ git rebase -i origin/<version_branch>

    Please pay attention to commit message format
        

  16. Implementor ensures all tests pass

    $ sbt test 

        

  17. Implementor sets <version_branch> branch to bug branch and pushes

    $ git checkout <version_branch>
$ git reset --hard review-sdl-123
$ git push origin <version_branch> # do not use the --force option here 

    If commit was a bug fix or a test on <version_branch> and a newer version branch exists:

     

    1. Implementor merges the change into the newer version branch, and fixes any conflicts:

      $ git checkout <new_version_branch>
$ git merge <version_branch>

    2. Implementor ensures all tests pass

      $ sbt test

      If tests fail due to incorrect conflict resolution, changes should be made and amended to the merge commit until tests pass:

      # make changes
$ git add <files>
$ git commit --amend

    3. Implementor pushes changes

      $ git push origin <new_version_branch> # do not use the --force option here



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

    $ git push --delete origin review-sdl-123
$ git branch -D review-sdl-123 

        

  19. Implementor prepares bug for validation, performing the following tasks:

    1. Choose "Review Accepted", marking JIRA bug "Resolved"

    2. Add commit ID to comments

    3. Add names and locations of any new/fixed tests in scala-new to comments

    4. Assign to TL
  • No labels