diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-28 09:19:41 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-28 09:19:41 +0000 |
commit | a27c8b00ebf173659f22f53ce65679e94e7dfb1b (patch) | |
tree | 02c68ec259348b63c6328896aa73265eb7b3d730 /dm-packaging/CHECKLIST | |
parent | Initial commit. (diff) | |
download | debian-keyring-upstream.tar.xz debian-keyring-upstream.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/CHECKLIST | 82 |
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. + |