It was brought to my attention that some folks have misconstrued my message in a number of ways, so I'd like to clarify it. I was encouraged to send this mail to all the original recipients, but followup should probably happen privately or on the -vote list. Mr. Welton brought up a specific issue, and I was (and am) trying to generalize from it to describe areas where I think Debian's internal processes need to be worked out. So, let me try and restate some of my points, with a clear line of demarcation between the general and the specific: #1 THE GENERAL: It would be unacceptable for a sponsoring host to unilaterally render project machines unavailable for long periods and, at the same time, not offer any explanation to the Debian Project Leader (DPL) or Debian System Administration team (DSA), and not allocate any of their personnel to rectifying the problem. THE SPECIFIC: Brainfood did in fact contact DSA with an explanation shortly after the incident occurred. It was also a topic of discussion on the #debian-devel IRC channel almost immediately (I can vouch for this, as I was there). #2 THE GENERAL: If I were the DPL, there were a security incident that involved a major project resource and I hadn't already been contacted, I'd be on the phone to the sponsors within minutes of hearing about it. (As with most tasks, this is something that the DPL can delegate.) THE SPECIFIC: It's my understanding that Brainfood was in contact with the DSA team about this particular incident very shortly after it happened. The current DPL has delegated responsibility for this sort of situation to DSA. (See Ben's email in this thread.) #3 THE GENERAL: Sponsors cannot be expected to immediately disclose all details of a given incident. It can take a lot of time to get a complete picture of a compromise and to assess the breadth of its impact. It's also possible that an incident can be caused by something a Debian developer does, in which case there may be a disciplinary result that may need to be handled with some discretion (see the Debian Machine Usage Policy: <http://www.debian.org/devel/dmup>). THE SPECIFIC: At present, I don't know any of the details of the problem at Brainfood, and I wouldn't expect to since I am not the DPL or a member of DSA. We have no reason to suspect that a Debian developer had anything to do with the present situation (I was asked to specifically clarify that point). #4 THE GENERAL: The DPL should be in the loop in situations like this. THE SPECIFIC: Ben said that Brainfood had not contacted him on this, but that he hoped they had contacted DSA, as they have done. This is fine because it's how Ben wants to manage things. Were I the DPL, I'd want to have a greater level of personal involvement in issues like this -- but that's my preference, and not necessarily every person's style or preference. #5 THE GENERAL: We should hold all Debian personnel, including the DSA team, to standards of responsibility and conduct, not just package maintainers. With power comes responsibility, and if a delegate of the DPL is unable or unwilling to meet those responsibilities, he needs to be thanked for his past services and replaced. It's my feeling that there should not be any such thing as an inactive delegate. If there is no need for a specific position, it can be eliminated (except for those positions that the Constitution specifically mandates must exist, like Project Secretary). THE SPECIFIC: There has been no official announcement of the ongoing service outage by the DSA team, and that disappoints me. I think someone in possession of the facts should make such an announcement, preferable to the debian-devel-announce list, so that our developers don't have to get the news from IRC. #6 THE GENERAL: Debian should have some documented procedures for event response. In particular, those should include notifying the developers when there is going to be a significant loss of service. THE SPECIFIC: I don't know that any such procedures officially exist, and if elected DPL, I would try to make sure that we develop some. #7 THE GENERAL: The DMUP could be expanded -- or a new document written -- to establish acceptable standards for Debian sponsors. This can help us to formally identify when a colocation facility may be unable to meet some or all of our needs. (For instance, some sites may not be willing to allow ssh connections, or may have bandwidth caps that would make it a bad idea to host certain project machines there.) THE SPECIFIC: As far as I know, we don't have any such "needs" statement in fixed form anywhere. The developers might be more understanding of certain usage restrictions placed on Debian machines if they understood the context in which those machines must operate. #8 THE GENERAL: We should post incident reports to debian-private (or debian-devel-announce) when a serious service outage occurs, and is expected to last (or has already lasted) for more than 24 hours. THE SPECIFIC: If done this week, such a message might have served to alleviate Mr. Welton's frustration a little bit, and might have spared me getting flamed on IRC. :) Finally, I'd like to state that I did not intend to disparage Brainfood in any way with my previous message. They have been a tremendously valuable -- indispensable, really -- asset to our Project for several years. If anyone on the Brainfood team felt attacked or slighted by my message, I apologize. In this latest incident they appear to have done everything right, but the lines of communication to Joe Q. Developer failed once the pertinent information was out of their hands. That's the part I'm disappointed about. I'd like to see the developer community apprised of service outages by the DPL or his delegate(s) when they occur. We should not expect our sponsors to communicate this information independently. It's nice when they do, but it's not their job to do so. As always, I welcome feedback on the above ideas. -- G. Branden Robinson | It's not a matter of alienating Debian GNU/Linux | authors. They have every right to branden@debian.org | license their software however we http://people.debian.org/~branden/ | like. -- Craig Sanders
Attachment:
pgp3kWf8flJIF.pgp
Description: PGP signature