Debian admin, keyring-maint and Request Tracker
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Summary
- -------
keyring-maint has switched to using Request Tracker[0] 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 keyring@rt.debian.org (for keyring-maint)
or
o admin@rt.debian.org (for DSA)
**NB:** You must put the phrase 'Debian RT' somewhere in the subject
line (case doesn't matter)[1].
Web Access
- ----------
RT lives at: https://rt.debian.org/ [2]
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:
master.debian.org:/home/debian/misc/rt-password
This account can also create tickets through the web interface, if you
prefer that to email[3].
Other teams
- -----------
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.
- --
James
[0] http://bestpractical.com/rt
[1] With the way RT works, it needs to send auto-replies to tickets on
creation so this is an unfortunate necessity to avoid problems
with spam.
[2] Currently it has a self-signed certificate, this'll be replaced
with a proper one from SPI in due course.
[3] 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/>
iQIVAwUBRgMzqtfD8TGrKpH1AQLN2xAAoOh5Kn1MvCfXWtowhFannLDxaA1OdHUz
Oy39z698Vmt6rgzIOmtPWTo1X8V7DRZFw3Tvo395PnVpqCVakaKwSgi4blDu8BVe
3codmQUgpZb0spipmz8LhMM6h0k1JfCgqYmUAho4Riw+Xe86dqjPPp2fHc6fdAuj
b7R8fpLEPYavBueZ0mbGuhiDn5ughwAOSh2tu7I5TonFU6Q1ZLukbGDG1BJUj1LO
+NHu5z6FqR+hWxVFNZEOqi/LZKGweI+mRsMlbNQ+Hl6Jlo7y5v2Z7p3EaBrlaLGX
plFKqcFGfbVFet7LcZ2Uim2K5itALXYUWjn+P4SrM3fDTPXOpRYT8L6IEBQmUUWw
JlWgZL0wl3Zc7Rw3au0362R1l3CyfYEc+Gi3rDECzLBhkvVGu/iqbxZITPGyG3SI
mZXR71V5dOwDqnxGBt42BKJe2IiiCzOHH8m7y39UMQIdsw1kB6BYRwjFgh3OIQuP
PweCHFsGWYUoFl4/fc9OMn3Bm1AcTem0svHG9tuvwfKdfgWsp4Ko5x5OXDnp8oAQ
e83ymomxfwFGXP4XBV+EfVpRlaRQPBAARGYxZdwMNyg1GehNaahce+tNQwxwJZNe
JEjyaR5glQiMkaR6WOhFXhc9M4YQnI93gxTGtaEssveStfoKLBgTd1fQQ2Mt+VVp
0mtHH72b0m0=
=OBXr
-----END PGP SIGNATURE-----
Reply to: