summaryrefslogtreecommitdiffstats
path: root/dm-packaging/CHECKLIST
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-28 09:19:41 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-28 09:19:41 +0000
commita27c8b00ebf173659f22f53ce65679e94e7dfb1b (patch)
tree02c68ec259348b63c6328896aa73265eb7b3d730 /dm-packaging/CHECKLIST
parentInitial commit. (diff)
downloaddebian-keyring-a27c8b00ebf173659f22f53ce65679e94e7dfb1b.tar.xz
debian-keyring-a27c8b00ebf173659f22f53ce65679e94e7dfb1b.zip
Adding upstream version 2022.12.24.upstream/2022.12.24upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'dm-packaging/CHECKLIST')
-rw-r--r--dm-packaging/CHECKLIST82
1 files changed, 82 insertions, 0 deletions
diff --git a/dm-packaging/CHECKLIST b/dm-packaging/CHECKLIST
new file mode 100644
index 0000000..d19a603
--- /dev/null
+++ b/dm-packaging/CHECKLIST
@@ -0,0 +1,82 @@
+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.
+