remove obsolete docs

git-svn-id: svn+ssh://svn.debian.org/svn/secure-testing@32619 e39458fd-73e7-0310-bf30-c45bca0a0e42

1 files changed, 0 insertions, 152 deletions

diff --git a/doc/how-to-DTSA b/doc/how-to-DTSA
deleted file mode 100644
index 3958a8186e..0000000000
--- a/doc/how-to-DTSA
+++ /dev/null
@@ -1,152 +0,0 @@
-20:40 < micah> its good you are going through this, so we can note these 
-               various undocumented things that are necessary
-20:44 < micah> sf: its like a quest
-20:45 < sf> the secure-testing adventure
-
-
-Upload
-======
-
-The upload can be done by any DD and is described in
-.../website/uploading.html.
-
-If the orig.tar.gz is already on security.debian.org (either stable-security
-or testing-security), then DON'T include it. Otherwise a bug in dak will
-prevent the buildds from building it.
-
-It is a good idea to check in the buildlog that all new patches
-actually get applied. Maybe you forgot to put them in patches/series
-or because of some bug dpatch ignored a patch.
-
-Use debdiff, interdiff etc. Use debdiff on the binary packages, too.
-
-The distribution needs to be "testing-security".
-
-If you append something to the version number currently in testing, use something
-like "+wheezy1" or ".0wheezy1". A simple "wheezy1" is not enough because of binNMUs
-adding "+b1".
-
-dcut does not seem to work on security-master.debian.org, but someone
-in the sec_public group (micah, neilm, sf, jmm) can remove broken
-files from the upload queue when needed.
-
-
-
-Requirements
-============
-
-Only DDs in the sec_public (and possibly the security?) group can
-accept the uploads (or even login on klecker). They also need to be
-member of the alias that gets the unembargoed build logs. See #88 on
-rt.d.o.
-
-
-
-Autobuilds
-==========
-
-When you have the buildlogs and the builds look ok, you have to sign
-the changes file embedded in the buildlog and send it to the buildd
-[1]. If you use your own script to do that: the Subject needs to be
-exactly as in the buildlog mail, but with a "Re: " prepended.
-
-A summary which buildlogs have arrived for which packages is at [2].
-
-Some time after the buildd has received the signed .changes, it will
-upload the packages to klecker to
-/org/security.debian.org/queue/unembargoed/. "dak queue-report" gives
-an overview, what packages have arrived in the queue.
-
-If a buildd has problems: A list with the admins is at [3].
-
-[1] http://wiki.debian.org/Buildd/BuildLogs
-[2] http://www.sfritsch.de/~stf/secure-testing-buildlogs.html
-[3] klecker:/org/security.debian.org/doc/buildd-admins.txt
-
-
-
-Releasing the packages
-======================
-
-When all packages have arrived (or you want to release a subset
-because some buildds are broken), go to
-klecker:/org/security.debian.org/queue/unembargoed/
-
-You can compare against a package in stable/updates with
-LANG=en_GB ~joey/bin/diffpackages -d stable clamav
-
-Otherwise do some debdiffing to ensure that the filelists and
-dependencies look correct. You can do this by downloading the 
-binary packages from klecker and the compare them, like the following:
-
-         for i in *wheezy1*.deb; do
-	     oldpkg=$(echo $i | sed -e 's/+wheezy1//')                                       
-	     debdiff debian.netcologne.de/debian/pool/main/c/cupsys/$oldpkg $i               
-         done|less
-
-If everything looks good, you can install the packages in the security 
-archive with something like:
-
-dak new-security-install DTSA-36-1 mydns_1.1.0-7+lenny1_*.changes
-
-DTSA-36-1 is an identifier that should be the name of the new DTSA.
-However, every identifier can be used only once with dak. So if you
-need a second run, use DTSA-36-1a or DTSA-36-2.
-
-"dak new-security-install" gives you an advisory template. This is not
-used for DTSAs. Ignore it by choosing Approve to continue, if everything 
-seems ok. If for some reason the dak run is not what you want, (for example 
-not all the required arches are listed), you can just choose Quit to abort
-the dak run. Do not hit control-c or there will be problems. Quit will
-allow you to re-run "dak new-security-install" again with the same DTSA
-number without problems. 
-
-The dak options as they are presented are confusing:
-Approve, [E]dit advisory, Show advisory, Reject, Quit?
-
-Each of those can be triggered by their first letter (Q for quit, etc.), 
-its not clear why [E]dit looks different.
-
-After the dak run, the new packages appear on security.debian.org and
-the mirrors are notified. You should get a mail that the packages are
-installed in testing-proposed-updates.
-
-
-
-Announcing
-==========
-
-Currently, we are not doing DTSA announcements, and instead letting the
-scripts include them in the automatic security update emails sent to
-secure-testing-announce. However, the below information is kept for
-posterity.
-
-If there has been a new stable release since the last DTSA, change the
-code names in all the scripts and templates ;-)
-
-How to create the announcement and how to update the tracker is also
-described in .../website/index.html
-
-After you sent the announcement to the announce list, you need to
-accept the mail on the moderator's page [4]. The sec_public people
-should have the password.
-
-Currently sf and luk (and possibly joeyh) can put the new announcements
-on the website (it's on alius.turmzimmer.net). These two should not
-forget to "chmod g+w" and "chgrp sectadm" the files.
-
-[4] http://lists.alioth.debian.org/mailman/admindb/secure-testing-announce
-
-
-Troubleshooting
-===============
-
-- If something fails with releasing the built packages and you have to restart
-  dak, use a different DTSA version since they can just be used once.
-- If you think the .dak files are just tmp files and you delete them, move the
-  files from the queue into /org/ftp.root/pub/OpenSecurityUploadQueue and
-  wait for the cronjob to push this into the queue again with new .dak files
-  (check file permissions).
-
-22:37 < micah> sf: you got the key! now to rescue the princess
-