Anthony Towns wrote: > More generally, Joey's a member of DSA and as such has root on > security-master.d.o; if he really wanted to he could maintain the dak > install there (or an entirely different system) himself for security
I must not do that. Being a system administrator is not a green light for hacking in arbitrary services maintained by another team or person. This has been a rule for Debian admin for a long time and it actually grants that those who maintain a service really maintain it and ar not confronted with arbitrary changes made by others. Hence, DSA must not interfere with infrastructure maintained by other people. This rule is only broken when either the person maintaining a service has given their ok or when the service is harming something and somebody immediately needs to get something done hencely. Thus, I must not fiddle with the DAK installation on either spohr or klecker unless ftpmaster give their ok for that. > updates. The reason he hasn't already done that is precisely the above -- > keeping that stuff in order, and supporting new things like secure-apt, > and finding and fixing bugs in it is a distraction from the stuff he's > there to do. Being able to do stable updates entirely would have saved a lot of time, effort and nerves in the long term. Well. That's past anyway. > And obviously there are problems with the code that need fixing -- it's > not perfect, and even if it were we'd keep thinking up things it could > do better anyway. For example, at the moment Moritz and I are trying to > track down a bug where the s.d.o Release file fails to generate properly, > and where the update being processed fails to get copied from s.d.o > into ftp-master/proposed-updates. That's great to hear. A solution will help aba and zobel a lot. This issue has been mentioned to ftpmaster months if not years ago and several times. > And it has been fairly frustrating trying to do that for Joey, since when You should not do it for me but for Debian. > things don't get fixed perfectly the first time, they get treated as a > major catastrophe; and that's why things don't go smoothly all the time, Things don't have to be fixed in the first time. However, people should get a response when they ask, and in case of infrastructure issues a perspective. Even a response "umh... I don't know what's going on, I'll look into it when I find time" would be a good response. > It hasn't always been this way -- the last time the security team took > care of all that stuff themselves was prior to woody's release in 2002 > (which included the addition of ia64, hppa, mips, mipsel and s390). And > as much as Joey does complain when it breaks [1], going to anything else > would still be a major step backwards [2]. It's out of question that the current infrastructure, as long as it is working, is essential and that the security team would have a hard time supporting sarge and woody without it. However, hell freezes when the infrastructure is not working and those responsible for it don't respond and react. Maybe you remember the disaster that happened when sarge was released. > [2] "The security team is very thankful for the buildd network as it > simplifies the roll-out of security updates a lot. We couldn't > support our distributions without this buildd network. It is an > essential projects asset and an essential resource of the security > team." > -- http://lists.debian.org/debian-devel/2005/03/msg01830.html This can only be printed and framed lots of times. Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
