Hi, On 27/06/07 at 12:41 +0100, Anthony Towns wrote: > 5) The intial policy for the use of the Debian Maintainer keyring with the > Debian archive will be to accept uploads signed by a key in that keyring > provided: > > [...] > > * the Maintainer: field of the uploaded .changes file corresponds > with the owner of the key used (ie, non-developer maintainers > may not sponsor uploads) That sounds wrong. If I'm only listed as an Uploader for the package, I will only appear in the "Changed-By:" field, not in the "Maintainer:" field of the uploaded .changes. Also, If a DM is allowed to upload a package, why wouldn't he/she be allowed to sponsor uploads for this package? > [...] > * the most recent version of the package uploaded to unstable or > experimental includes the field "DM-Upload-Allowed: yes" > in the source section of its control file. > > * the most recent version of the package uploaded to unstable > or experimental lists the uploader in the Maintainer: or Uploaders: > fields (ie, non-developer maintainers cannot NMU or hijack packages) Using this "DM-Upload-Allowed: yes" solution really seems like an ugly hack. What if the package has a long list of Uploaders, with both DMs that should be allowed to upload, and DMs that shouldn't? This can easily be the case with some teams that automatically generate the Uploaders field from the changelog, or from a list of team members (pkg-gnome and pkg-ruby-extras are good examples). I would suggest either: (1) using a specific field, like "DM-Uploaders:", to list the actual DMs that should be allowed to upload the package. (2) doing all the checks inside dak (ie have the list of packages a DM is allowed to upload in dak). But that's difficult to manage in the case of DMs with a lot of packages (like DMs working in big teams). (3) not doing anything (the DM can upload any packages for which he is Maintainer/Uploader). But before giving him the DM rights, a mail is sent to all Maintainers and Uploaders of the packages that he/she will be allowed to upload, just to warn them. My preference goes to (1), then (3), then (2). -- | Lucas Nussbaum | lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Attachment:
signature.asc
Description: Digital signature