...
Recommendations for developers
General recommendations
- Always create a JIRA issue.
- Use meaningful comments when doing a Subversion commit.
- Always mention the JIRA issue that is related to your commit (e.g., "Fix for JIRA-123").
- When doing a commit based on a patch from a contributor, make sure to mention the contributor name in the comment (e.g. "Fix for JIRA-123. (Contributor name)" ).
- Never commit incomplete changes (Subversion is not a backup system).
- Working on experimental changes is encouraged, but in this case use a branch.
- Don't maintain Versions.txt anymore, we will extract release notes from JIRA starting from IzPack 4.0 and beyond.
- Subscribe to the SCM mailing list to get notified of SVN commits and JIRA activity.
- Subscibe to the developer mailing list to follow IzPack development conversations.
- Do not hesitate to pick new JIRA issues: both the other developers and the issue submitter will thank you for the work!
- When you start working on an issue, don't forget to mark it as in progress so that we know that you're solving it!
- For developing workflow will be: Open -> In progress -> Resolution -> Resolved -> Closed
- For language file update: Open -> Resolved -> Closed
- For more information about an issue please visit: What is an Issue?
Code reviews
Before merging a patch submitted by an external contributor, developers are expected to make a simple code review.
- Look at the code carefuly to ensure that it is of good quality
- Obviously... test it
- Attach your review to the related JIRA issue
- Send your review to the dev mailing-list.
In case no other developer makes a comment after a few days, you can act as you decided: accept or reject it!
Recommendations for contributors and issues reporters
...