Unofficial, unblessed debian-release list frequently asked questions:
Read http://www.debian.org/devel/testing first.
Q: Can you help me get a package out of the NEW queue?
- This is a job for the ftp masters, not the release team.
Q: Can you remove a binary package from unstable?
- This is a job for the ftp masters. File a bug against ftp.debian.org, with an explanation, requesting the removal of the packages.
Q: Can you let in package x which I'm not a maintainer?
- Get the maintainer to make a request to debian-release when it's appropriate. The maintainers usually have a better idea and may be able to explain any reasons why a package/version shouldn't be in testing.
Q: Can you upload a package for me?
- It's generally better to ask elsewhere. If you have an upload which fixes an RC bug then put the patch into the BTS, and tag the bug patched first. If your package is new and not related to any release blocking issues you should ask elsewhere.
Q: Can you remove package x from testing?
- This is best determined by a maintainer and thus they should make the request when possible. If the package has an RC bug against it, or is a release blocker then an explanation should be provided before consideration can be made.
Q: Can I get non-release critical uploads of a frozen package into testing?
- Maybe. Please provide details of what has changed (a changelog, and perhaps a diff). If code has changed in such a way that an RC bug may have been introduced ("breakage") then a wait of 20 days might be requested. Check first, then if you're confident, feel the changes are useful, and provide debian-release with appropriate details your upload might be accepted into testing.
Q: Can you change testing's code name or release number?
- That is a decision for the RM's. Unless the issue is a release blocker debian-release is not the appropriate forum for this discussion. Please see past threads on this issue before asking elsewhere.
Q: My package hasn't been uploaded for one or more architectures, can this be ignored?
Check the buildd logs ( http://buildd.debian.org ) for failures and queue status (see http://www.debian.org/devel/buildd/ ). See also http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-porting . If a rebuild is required ask the appropriate group via their e-mail address (read the developers reference for the adresses link). It's better to have a buildd build a package to make sure that one can be used to do any future security builds. If an architecture is too backed up the release team may decide to temporarily ignore it. Generally, if your package has binaries for an architecture in unstable or testing, then these binaries need to be built again for any new versions, or removed (see removing binary packages). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=258437 or http://www.debian.org/devel/testing under "My package is stalled because it's out of date on some architecture. What do I do?" may also be useful.
Q: Can you change the release process so that x?
See ReleaseProposals and feel free to contribute there.
Q: Can you change the release documentation?
Release documentation is handled by debian-doc? A copy of the release notes is under development at http://cvs.debian.org/ddp/manuals.sgml/release-notes/en/release-notes.en.sgml?cvsroot=debian-doc
Other resources? debian-installer (d-i) info?