Committing Changes
This section is mostly about dpkg conventions, and not too much about Arch. If you follow these conventions, the job of merging in your changes is a lot easier.
ChangeLog
All changes to the dpkg source, including new or removed files, must be documented in the top-level ChangeLog. On the development branch, changes underneath the po/ directory must be documented in po/ChangeLog instead.
Changes to debian/changelog must not be documented, this is the only exception.
When applying patches from others you must place their name and e-mail address in the header, and not your own. If you have your own changes, commit them separately afterwards with your own entry.
Development branch format
GNU standard format should be used. Multiple commits from the same person, on the same day should be separated by a blank line only, a new header is not required.
2005-01-02 Scott James Remnant <scott@netsplit.com>
* path/to/simple: A change of day has a new header.
2005-01-01 Scott James Remnant <scott@netsplit.com>
* path/to/simple: Back to me, no functions in this file.
2005-01-01 Joe Bloggs <jbloggs@debian.org>
* path/to/file (function): Commit from somebody else interrupts mine
wrap changelog entries like this.
* path/to/another (func): When multiple files are changed, don't leave
a blank line.
2005-01-01 Scott James Remnant <scott@netsplit.com>
* path/to/file (function): My second commit of the day.
* path/to/file (function): My first commit of the day.
Stable branch format
The format is currently non-standard, I use the following script to generate the lines for me.
There should be one ChangeLog entry per commit. Multiple commits should have multiple ChangeLog entries.
debian/changelog
Changes that fix bugs or are otherwise notable must be documented in debian/changelog. All bugs, including merges, that are closed should be listed. I prefer the following form of entry, note the extra spaces and full stops.
* Fixed some problem. Closes: #nnnnnn, #yyyyyy.
Various changes, for example translations, are listed in sub-sections.
* Updated Translations:
- Klingon. Closes: #nnnnnn.
Arch Commit Log
Along with the actual changes themselves Arch stores a log message and summary describing the changes. There are a few rules I like to play by which make identifying changes easier.
- The Summary line should be a one-line description of the changes
The Keywords line should list all relevant pseudo-tags (see debian/pseudo-tags and bug numbers. Architecture support should use arch:XX and translations should use intl:XX.
The log message itself should be a copy of the appopriate ChangeLog entries.
I have a script to do this for me, and I strongly recommend you use the same one as it does everything for you.
Committing
To commit, you do the following.
Check ChangeLog has a new entry with the right author, and lists all of the changes that have been made.
If any of the changes close bugs or are otherwise notable, check debian/changelog has entries for them.
Run tla-make-changelog, this will give you an editor. Fill in the Summary line and add any appropriate pseudo-tags to Keywords.
Run tla commit.
If you wish to make your changes public now, run tla archive-mirror.
You're now free to inform the world about your changes, if they're good, I'll merge them into my archive.