...
Search for an issue in JIRA that represents the change you would like to make or bug to fix. If one does not exist, create a issue. See How To Report a Bug for creating issues and what information/discussions should take place in JIRA.
- Assign the issue to your self. You may need to request permissions to modify the bug by sending an email to dev@daffodil.apache.org
Create a GitHub fork of the Daffodil GitHub mirror and clone it. This remote will be your
origin
remote:Code Block language bash $ git clone git@github.com:username/daffodil.git $ cd daffodil
Add the ASF upstream repository as a new git remote, calling it asf:
Code Block language bash $ git remote add asf git://git.apache.org/incubator-daffodil.git $ git fetch asf
Create a new branch off of the
asf/master
branch nameddaffodil-XYZ-description,
whereXYZ
is the JIRA bug number and-description
is an optional, very short description of the bug making it easier to differentiate between multiple development branches. For example:Code Block language bash $ git checkout -b daffodil-123-bitorder-feature asf/master
- Make changes to the branch, frequently adding new commits. Code changes should follow the Daffodil Code Style Guidelines and should add appropriate tests using the Test Data Markup Language (TDML) or unit tests. Tests in
src/test/scala-debug
that are fixed should be moved intosrc/test/scala
. When changes are complete, rebase your commits onto
asf/master
and verify that all tests pass:Code Block language bash $ git fetch asf $ git rebase asf/master $ sbt test
Note that you should not usegit pull
orgit merge
to sync to theasf
repo. Alwaysfetch/rebase
and avoid merge commits. Pull requests containing merge commits will be rejected.If multiple commits were made,
git rebase -i asf/master
should be used to interactively rebase and squash the commits into the smallest number of logic logical commits. Most commonly this should be a single commit, but there may be some rare cases where multiple commits make sense.Ensure each commit has an appropriate and descriptive commit message. The first line of a commit message should contain a short (~50 characters) description of the commit. The second line should be blank, followed by a longer description of the change, wrapped at 72 characters. This long description should describe what was changed in the commit and, more importantly, why those changes were made. The 'what' can be determined by inspecting the code, but the 'why' is often less obvious. At the end of the commit should be a blank line followed by a reference to the JIRA bug, e.g. DAFFODIL-123. Multiple bugs referenced in a single commit should be separated by a comma on the same line. An example of a commit message is:
Code Block language text Add support for the dfdl:bitOrder feature Longer explanation of what changes were made to support the bitOrder feature, including a description of why the changes were made. Multiple lines are wrapped at 72 characters DAFFODIL-123
Push your branch to your fork:
Code Block language bash $ git push origin daffodil-123-bitorder-feature
- Use the GitHub interface to create a pull request for your new branch.
- Mark the JIRA bug as
Patch Available
. - Wait for review comments. There must be at least two +1's from other committers before the patch can be merged. If there are any comments or the automated Travis CI build fails, repeat from step 5 to make the necessary changes, rebase, and push to your GitHub fork. The pull request is automatically updated once you push your changes.
- Once at least two +1's are received from committers, a committer can accept the pull request. This should be done using the
Rebase and Merg
e option to avoid merge commits. - Mark the JIRA bug as
Resolved
. If you would like to clean up, you can now delete your development branch, either via the GitHub user interface or:
Code Block language bash $ git push --delete origin daffodil-123-bitorder-feature $ git branch -D daffodil-123-bitorder-feature