[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian services and responsibility



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: pgpwOw7LPTXY7.pgp
Description: PGP signature


Reply to: