Differences between revisions 34 and 36 (spanning 2 versions)
Revision 34 as of 2008-02-15 12:51:47
Size: 5981
Comment:
Revision 36 as of 2008-02-16 13:25:44
Size: 8387
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
||<tablewidth="100%"style="border: 0px hidden ;">~-Translation(s): none-~ ||<style="border: 0px hidden ; text-align: right;"> (!) ["/Discussion"] ||
[[BR]]
||<tablewidth="100%" tablestyle="border: 0px hidden ; text-align: center;"> http://www.debian.org/logos/openlogo-nd-50.png http://www.debian.org/Pics/debian.png ||

== Contents ==
[[TableOfContents(3)]]
Line 7: Line 14:
A Debian Maintainer has their key in the debian-maintainers keyring (available in the debian-maintainers package). Debian Maintainers have their keys in the debian-maintainers keyring (available in the debian-maintainers package).
Line 14: Line 21:
A developer should only advocate a candidate if they are familiar with the candidate's existing work in Debian and believe it to be of a suitable standard both technically and socially. A Debian Developer should only advocate a Debian Maintainer candidate if they are familiar with the candidate's existing work in Debian and believe it to be of a suitable standard both technically and socially.
Line 16: Line 23:
Developers advocating DMs (or potential DDs for that matter) must go into a bit more detail in their advocacy. Debian Developers advocating Debian Maintainer candidates (or potential Debian Developers for that matter) must go into a bit more detail in their advocacy.
Line 18: Line 25:
If the prospective DM has done "a great job", please explain what "a great job" means -- is there something special she/he's done, or is it that whatever she/he's working on is particularly important, or is she/he remarkably consistent, or what? What's she/he actually done that's earnt your trust? What makes her/him special compared to the other folks who're helping Debian? What in particular about her/his work should people lurking on the debian lists be trying to emulate if they want to be a DM or a DD? If the Debian Maintainer candidate has done "a great job", please explain what "a great job" means -- is there something special the candidate has done, or is it that whatever the candidate is working on is particularly important, or is the candidate remarkably consistent, or what?
Line 20: Line 27:
For example, if the prospective DM has good packaging skills, go into a bit more detail about what's convinced you he's got those skills? Are there any difficult bugs you've worked together on, or new features he's done a good job of getting into Debian, or has he been particularly helpful supporting users, or...? What has the candidate actually done that has earnt your trust? What makes the candidate special compared to the other folks who are helping Debian? What in particular about the candidate's work should people lurking on the Debian lists be trying to emulate if they want to be a Debian Maintainer or a Debian Developer?

For example, if the Debian Maintainer candidate has good packaging skills, go into a bit more detail about what's convinced you the candidate has got those skills? Are there any difficult bugs you've worked together on, or new features the candidate has done a good job of getting into Debian, or has the candidate been particularly helpful supporting users, or...?
Line 34: Line 43:
Once you have your key in the keyring, you will be able to upload packages, where the following conditions hold: Once you have your key in the debian-maintainers keyring, you will be able to upload packages, where the following conditions hold:
Line 39: Line 48:
Line 47: Line 57:
Maintainers must reconfirm their interest annually to keep their keys in debian-maintainers keyring. Maintainers must reconfirm their interest annually to keep their keys in the debian-maintainers keyring by filing a signed bug report against the [http://packages.qa.debian.org/debian-maintainers debian-maintainers package].
Line 51: Line 61:
File a bug report against the [http://packages.qa.debian.org/debian-maintainers debian-maintainers package] to replace/update an existing key or remove a key from the debian-maintainers keyring. If you are replacing a key with an entirely new key (rather than just updating the expiry date or subkeys) you should read the [http://keyring.debian.org/replacing_keys.html rules for key replacement in the debian-developers keyring]. File a signed bug report with a jetring changeset against the [http://packages.qa.debian.org/debian-maintainers debian-maintainers package] to replace/update an existing key or remove a key from the debian-maintainers keyring. If you are replacing a key with an entirely new key (rather than just updating the expiry date or subkeys) you should read the following rules (taken from the [http://keyring.debian.org/replacing_keys.html rules for key replacement in the debian-developers keyring]).

=== Rules for key replacement in the Debian Maintainers keyring ===

These are the rules governing what happens if a Debian Maintainer (Alice) wishes to replace her existing key (X) in the debian-maintainer keyring with an entirely new key (Y).

 1. Key Y must be signed by an active Debian Developer (Bob) whose key is in the debian-developers keyring.
 1. Alice files a signed bug report with a jetring changeset to the bug tracking system against the [http://packages.qa.debian.org/debian-maintainers debian-maintainers package].
 1. Alice must get a Debian Developer (ideally not Bob) to sign a message requesting the replacement of key X with key Y on behalf of Alice. That statement should contain the key fingerprints of both keys X and Y and must be posted as a follow up to the bug report filed by Alice.
 1. If the reason for replacement is 'key X is compromised or no longer valid' then the request for replacement must be accompanied by a revocation certificate for key X.
 1. If the reason for the replacement is 'key X was lost' then a revocation certificate should be provided if possible.
 1. If the reason is 'I wanted a new key' then the new key must be strictly more secure than the old key and 'reasonably' connected where 'reasonably' is left up to the debian-maintainers keyring administrator and varies depending on the circumstances of the Debian Maintainer in question.
 1. Anything else is at the debian-maintainers keyring administrator's discretion and, in general, arbitrary key replacements without good cause will be rejected.

== Statistics ==

attachment:dm.png

Translation(s): none

(!) ["/Discussion"]

?BR

http://www.debian.org/logos/openlogo-nd-50.png http://www.debian.org/Pics/debian.png

Contents

?TableOfContents(3)

Introduction

Debian Maintainers are people who are not full developers but have a restricted ability to upload packages to the Debian archive.

The Debian Maintainers concept was introduced on 5th August 2007 by [http://www.debian.org/vote/2007/vote_003 General Resolution].

Overview

Debian Maintainers have their keys in the debian-maintainers keyring (available in the debian-maintainers package).

This keyring is used by dak on the Debian archive as part of the checks as to whether an uploaded package is to be accepted.

Packages signed by a key in the debian-maintainers keyring will be accepted if the package is not new and the previous version of the package contains the maintainer in the Maintainer or the Uploaders control fields and has the DM-Upload-Allowed control field present.

Advocating a Maintainer

A Debian Developer should only advocate a Debian Maintainer candidate if they are familiar with the candidate's existing work in Debian and believe it to be of a suitable standard both technically and socially.

Debian Developers advocating Debian Maintainer candidates (or potential Debian Developers for that matter) must go into a bit more detail in their advocacy.

If the Debian Maintainer candidate has done "a great job", please explain what "a great job" means -- is there something special the candidate has done, or is it that whatever the candidate is working on is particularly important, or is the candidate remarkably consistent, or what?

What has the candidate actually done that has earnt your trust? What makes the candidate special compared to the other folks who are helping Debian? What in particular about the candidate's work should people lurking on the Debian lists be trying to emulate if they want to be a Debian Maintainer or a Debian Developer?

For example, if the Debian Maintainer candidate has good packaging skills, go into a bit more detail about what's convinced you the candidate has got those skills? Are there any difficult bugs you've worked together on, or new features the candidate has done a good job of getting into Debian, or has the candidate been particularly helpful supporting users, or...?

Becoming a Maintainer

To become a Debian Maintainer, you must:

  • agree to the [http://www.debian.org/social_contract social contract] and [http://www.debian.org/social_contract#guidelines DFSG]

  • agree to the [http://www.debian.org/devel/dmup Debian Machine Usage Policies] (dmup)

  • publically state your agreement to the above two documents, signing your declaration with your OpenPGP key. Most people will post their declaration to the [http://lists.debian.org/debian-newmaint debian-newmaint mailing list]

  • have your PGP key signed by at least one (but ideally more than one) Debian Developers
  • have at least one (but preferably more) Debian Developers advocate you. This is usually a signed mail to debian-newmaint (often a reply to your declaration mail)
  • submit a bug report with a jetring changeset to the bug tracking system, filed against the [http://packages.qa.debian.org/debian-maintainers debian-maintainers package]. Use only URLs from debian.org for the agreement and advocates fields of the jetring changeset

  • there will be a delay of four days after the bug report has been submitted to wait in case of objections or any more advocacies from Debian Developers

Uploading packages

Once you have your key in the debian-maintainers keyring, you will be able to upload packages, where the following conditions hold:

  • the package already lists you in the Maintainers or the Uploaders control fields

  • the package already has the DM-Upload-Allowed: yes control field

  • the package is not NEW

dpkg caveat

Until recently dpkg did not understand the DM-Upload-Allowed field and would not add it to the DSC. You need to either have dpkg version >= 1.14.16 (you should use the most up to date tool versions anyway ;-)) or prefix it with 'XS-' for it to make it into the DSC file.

Key Changes

The debian-maintainers keyring is updated with a new version of the [http://packages.qa.debian.org/debian-maintainers debian-maintainers package]. Its keys are not kept in sync with the keyservers. All changes to the debian-maintainers keyring are done with jetring changesets.

Annual ping

Maintainers must reconfirm their interest annually to keep their keys in the debian-maintainers keyring by filing a signed bug report against the [http://packages.qa.debian.org/debian-maintainers debian-maintainers package].

Key replacement/removal

File a signed bug report with a jetring changeset against the [http://packages.qa.debian.org/debian-maintainers debian-maintainers package] to replace/update an existing key or remove a key from the debian-maintainers keyring. If you are replacing a key with an entirely new key (rather than just updating the expiry date or subkeys) you should read the following rules (taken from the [http://keyring.debian.org/replacing_keys.html rules for key replacement in the debian-developers keyring]).

Rules for key replacement in the Debian Maintainers keyring

These are the rules governing what happens if a Debian Maintainer (Alice) wishes to replace her existing key (X) in the debian-maintainer keyring with an entirely new key (Y).

  1. Key Y must be signed by an active Debian Developer (Bob) whose key is in the debian-developers keyring.
  2. Alice files a signed bug report with a jetring changeset to the bug tracking system against the [http://packages.qa.debian.org/debian-maintainers debian-maintainers package].

  3. Alice must get a Debian Developer (ideally not Bob) to sign a message requesting the replacement of key X with key Y on behalf of Alice. That statement should contain the key fingerprints of both keys X and Y and must be posted as a follow up to the bug report filed by Alice.
  4. If the reason for replacement is 'key X is compromised or no longer valid' then the request for replacement must be accompanied by a revocation certificate for key X.
  5. If the reason for the replacement is 'key X was lost' then a revocation certificate should be provided if possible.
  6. If the reason is 'I wanted a new key' then the new key must be strictly more secure than the old key and 'reasonably' connected where 'reasonably' is left up to the debian-maintainers keyring administrator and varies depending on the circumstances of the Debian Maintainer in question.
  7. Anything else is at the debian-maintainers keyring administrator's discretion and, in general, arbitrary key replacements without good cause will be rejected.

Statistics

attachment:dm.png

IRC Channel

#debian-maintainer at irc.debian.org


Page Copyright

License

["GPLv2"]

Authors

JonDowland AnibalMonsalveSalazar

see ?LicencingTerms for info about wiki content copyright.