A Checklist of things to do when making a commit
When we commit a change, or fix a bug, we should follow a standard guideline. I (Ali) am probably the most guilty of ignoring these rules, but this sequence should make all our lives easier.
Before you do anything
Ensure that you are addressing a bug on the Launchpad (or whatever bug tracking we happen to be using in the future). This might be a publicly reported bug, or it may not exist yet. If the report does not exist yet, please report it as a bug or a feature enhancement. This is really easy using the built-in bug report tool.
This way of doing things is vaguely XP-ticket-style, and in my experience works rather well, and will be invaluable when we have hundreds of developers!
Have your code reviewed
Making commits
Commit messages can be short, but should contain the bug number that the commit is for. It is envisaged that each change may have >=1 commit, and so we can correlate them with the bug report.
Once the bug is fixed, or feature is implemented
Mark the bug report as "fix committed" awaiting the next release, where it will be marked "fix released". Then enter information in the CHANGELOG file (currently pida/data/CHANGELOG) about the change. The information in the CHANGELOG should be of the form:
* <change made> (<person making change>) #<bug number>
This will allow us to keep track of the hows, whos, and wherefores.
It should be noted that the CHANGELOG file is for *users* not for developers. The developer changelog should be the commit history.
Summary
To summarize the above:
- Make a bug report
- Implement changes with multiple commits each mentioning the bug number
- Mark the bug as fix committed
- Update the changelog
