0. "Frozen"

	The traditional "frozen" distribution does not and will not exist
	during the woody freeze. Uploads of packages should continue to
	go to unstable and will be accepted (or not) from there.

	As packages get frozen, updates uploaded to unstable will cease
	being considered for inclusion in testing.

1. Crypto

	Packages which are only in non-US/main due to crypto (and not
	due to patents or dependencies) will be able to be included
	in main in woody. None of these will be included in the base
	system. OpenSSL, ssh and gpg are likely to be added to standard
	if they're moved to main in time. Note that the OpenSSL package,
	at least, will need to have its patented bits disabled (see Red
	Hat's source rpm, eg) before this is okay.

	The archive scripts need to be modified to support the
	various requirements the US government place on cryptography
	exporters. These are hoped to be complete in the next week or two.
	Please do not upload crypto to main at this point. There'll be a
	loud notification when that is okay.

2. woody-proposed-updates

	There are a few ports with significant numbers of out-of-date
	packages in testing (arm, hppa, m68k and powerpc in particular).
	Fixing this by uploading to unstable is generally not possible,
	so porters may autobuild any out of date packages and upload
	them to "woody-proposed-updates" (instead of "unstable"), at
	which point they'll be added to testing assuming they've been
	built against the correct libraries.

	Additionally, for packages that are frozen or whose unstable
	version cannot be included, the security team can upload security
	updates directly to w-p-u. Sourceful uploads need to be approved
	by either myself (as release manager), the security team (for
	security updates which should be the primary reason for source
	updates), or ftpmaster (just in case). This is done by adding
	a line "<source package name> <source version>" to one of the
	files in /org/ftp.debian.org/testing/tpu-approved on auric.

3. Python policy

	Python policy has changed significantly, as discussed on the -python
	list. See http://people.debian.org/~flight/python/python-policy.txt

4. Non release critical bugs

	Bashisms generally aren't release-critical, even when they're in
	scripts marked #!/bin/sh. They may be release-critical if their
	breakage causes other problems that are release-critical if they
	ever happen.

	"Doesn't build" bugs are only RC if the package has already been
	built on the given architecture for an earlier version, and the
	new version hasn't been built by either the maintainer or the
	autobuilders. This generally means "binary-all target is broken"
	isn't release-critical, eg.