Debian admin, keyring-maint and Request Tracker
-----BEGIN PGP SIGNED MESSAGE-----
keyring-maint has switched to using Request Tracker and DSA are
going to trial it too. If you have any new (or outstanding) DSA or
keyring requests, please (re)send them to either:
o email@example.com (for keyring-maint)
o firstname.lastname@example.org (for DSA)
**NB:** You must put the phrase 'Debian RT' somewhere in the subject
line (case doesn't matter).
RT lives at: https://rt.debian.org/ 
Anyone can view the public queues and tickets by logging in as the
'guest' user with the password 'readonly'.
Debian developers can also log in as the 'debian' user. The password
for this account is available from:
This account can also create tickets through the web interface, if you
prefer that to email.
If any other teams/groups want to use rt.debian.org to track their
requests, they're welcome to do so, just send us the details in an RT
ticket for DSA.
(Boring details on) Queues and Users
The current setup of queues and users in RT is a work in progress and
may change depending on how well things work out. For example, with
users we could look at either integrating RT with LDAP or using one of
the auto-account-creation hacks for RT rather than having one shared
account for DDs.
Right now, the queues are as follows:
o keyring [public]
o DSA [public]
o keyring - incoming
o DSA - incoming
o DSA - private
With new tickets defaulting to the 'incoming' queues which are not
world readable. This is so we can have tickets mailed in which
shouldn't immediately become public, e.g. '/bin/lala is a 4755 bash on
master' or whatever. The idea is that almost every ticket will move
from the incoming queue to the public queue the first time a human
sees/touches it. There's a private DSA queue for tickets that really
should remain private but these should be the vast minority of tickets
with the majority being in the public queue.
 With the way RT works, it needs to send auto-replies to tickets on
creation so this is an unfortunate necessity to avoid problems
 Currently it has a self-signed certificate, this'll be replaced
with a proper one from SPI in due course.
 The 'guest' account can't create tickets because it has such a
weak password it might as well not have one (in fact, if that were
an option in RT, it wouldn't).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
-----END PGP SIGNATURE-----