What to do when reviewing a changeset:

* If you advocate a new DM, ask someone else to add the key. Do not add it
  yourself.

* Check the changeset. This runs the test suite on it to sanity check it,
  and if it tests ok, displays a diff of exactly what changes
  the changeset will introduce.
  
  ./review changeset

  Make sure nothing fishy is going on..

* If the changeset is adding a new DM, you'll want to use keycheck to
  generate a report. The report is put in the KeyCheck field of the changset.

  ./keycheck changeset

* Review the changeset:

  - Does the KeyCheck look ok?
  - Is the key signed by more than one DD? At least one DD?
    More than 1 is preferred.
  - Is there at least one advocate?
  - Does the applicant acknowledge Debian's social contract, free software
    guidelines, and machine usage policies?
  - Does the applicant already maintain at least one package in the
    archive? (Listed as the Maintainer or in Uploaders) Does the package
    source have XS-DM-Upload-Allowed: yes set? If not, the applicant isn't
    ready to upload, and should be told what needs to be done.

* If the changeset and applicant look ok to add:

  1. Fill in the Changed-By field with your name and email address.
  2. jetring-accept debian-maintainers changeset
  3. dch "Added Debian maintainer Their Name. Closes: #XXXXX"
     (Please make sure that the changelog is marked UNRELEASED until
      a release is made. Set DEBCHANGE_RELEASE_HEURISTIC=changelog
      in ~/.devscripts.)
  4. git add debian-maintainers/*
  5. debcommit -a; tagpending; git push origin master

* If the changest has been changed:

  Note that this should rarely be needed. It's better to make a new
  changeset changing whatever needs to be changed.

  1. mv debian-maintainers/changeset .
  2. Edit debian-maintainers/index to remove changeset entry
  3. jetring-accept debian-maintainers changeset
  4. git add debian-maintainers/* 
  5. git commit
  6. git push origin master

* To make a release:

  1. dch -r
  2. Tag your new version with a signed tag. With devscripts >= 2.10.10,
     set DEBCOMMIT_SIGN_TAGS=yes in ~/.devscripts and then you can just use
     debcommit -r to create a signed tag.
  3. git push origin master && git push --tags
  4. Upload the new version of the package so changes will go live and the new 
     DMs can upload their packages. (This will also automatically cause an
     announcement to be sent.)


Adding someone to the DM keyring team:

The procedure is much the same except the changeset is added to the admins
keyring. When generating the changeset, you may want to install the
signing-party package and use:

	pgp-clean -s keyid | sed 's/^/  /'

This will strip signatures from the key, saving a lot of space if the
key has tons of signatures.

Of course the new team member should be given commit access on alioth.
And team members can add themselves to Uploaders if desired, although
the initial upload has to be done by one of the prior Uploaders or
ftp-master will require a manual accept of the package.