Patch Submission
The ideal way to submit changes for inclusion is as Arch changesets and branches. Arch is a distributed version control system, so there's no need for commit rights on any central server. To get your changes included, you simply need to mail the list with your repository details and what you want merged in.
There are a few procedures that make that easier.
Ongoing development
If you plan to work on dpkg regularly, you'll probably want to create your own development branch as outlined in ArchRepository. This is especially appropriate if you are doing translation work, or any other work focussing on one particular area where all of your changes are likely to be merged in.
When you want your changes pulled in, make sure your mirror is up to date and then simply send a mail like this to debian-dpkg@lists.debian.org:
From: Joe Bloggs <jbloggs@debian.org>
To: debian-dpkg@lists.debian.org
Subject: New changes to be pulled
Please sync with my archive:
jbloggs@debian.org--2005/dpkg--devel--1.13
http://people.debian.org/~jbloggs/arch/jbloggs@debian.org--2005
The URL should be the address of a public mirror of your archive, for anyone who hasn't yet registered your archive. The mail must be signed with the same key as the changesets within the archive.
Single changesets
Very small and trivial changes often fit within a single commit, made on your own development branch. Generally this is only appropriate if you were doing other work already and you tripped over a small problem that can be merged in separately.
To ask for that single changeset to be cherry-picked into the archive, send a mail like this to debian-dpkg@lists.debian.org:
From: Joe Bloggs <jbloggs@debian.org>
To: debian-dpkg@lists.debian.org
Subject: New change to be applied
Please apply patch-14 from my archive:
jbloggs@debian.org--2005/dpkg--devel--1.13
http://people.debian.org/~jbloggs/arch/jbloggs@debian.org--2005
The URL should be the address of a public mirror of your archive, for anyone who hasn't yet registered your archive. The mail must be signed with the same key as the changesets within the archive.
Do not be surprised if you are asked to prepare a submission branch instead.
Submission branches
Small changes and bug fixes often lead into quite lengthy development, or at least consist of one or more commits. Cherry picking multiple commits off a development branch which contains other work becomes reasonably tricky, especially if those other changes could be merged at a later date. For this reason it's far preferred if you prepare a submission branch and offer that for merging.
Submission branches are created in the same way as development branches (see ArchRepository/YourOwnBranch), they are tagged off the main dpkg branch rather than your own and the branch name should be something useful and meaningful.
$ tla tag -S scott@netsplit.com--2005/dpkg--devel--1.13 \
dpkg--dselect-utf8-support--1.13
In this instance, we're naming our branch dselect-utf8-support. You should confine work on this branch to that goal, and when ready send a mail asking for changes to be merged from it as if it were a development branch.
If you've already made the changes on your development branch, there's no need to do them again. Using the tla replay command you can cherry-pick changes from your development branch onto the submission branch and offer them that way.
$ tla get dpkg--dselect-utf8-support--1.13 dpkg-1.13 $ cd dpkg-1.13 $ tla replay dpkg--devel--1.13--patch-14 $ tla replay dpkg--devel--1.13--patch-15 $ tla-make-changelog $ tla commit
Here we've taken patch-14 and patch-15 from your development branch, applied them to the working copy of your submission branch and committed the changes. You're now ready to offer this branch for merging, and when a problem is found can simply fix it on the submission branch.