On Tue, Jul 05, 2005 at 08:18:47AM +0200, Andreas Tille wrote: > it might be only me that I missed something on the schedule which I'm really > eager to: A session where we could discuss problems in our organisation. I've been thinking the same thing. > I was impatiently waiting for some words of the DPL or a DPL team member > which concerned the problem of missing security updates in June. My DPL report is long overdue, and I do have an item about exactly that. I've been talking to lots of people. Here's the current text from this item in my DPL report draft. Status of Security Support for Released Distributions As has been covered in the press (also see Joey Hess's commentary) and in Martin "Joey" Schulze's blog, Debian has been sluggish with security updates for Sarge (and Woody, the previous stable release, which we plan to support until June 2006). I think it's worth pointing out to anyone who's not aware of it that security updates resumed at the end of June. Steve Langasek, one of our Release Managers, informs me that all known issues blocking the current round of security advisories have been fixed. After extensive conversations with many people, I diagnose two factors that led to this problem: 1) our failure to scale the security team in line with the demands being placed on it; and 2) a failure of process in making the security updates that were prepared release in a timely fashion. Javier Fernández-Sanguino Peña warned us of the first issue two years ago, in his "Security in Debian" talk at DebConf 3. The security team has received offers of help, and I've been carbon-copied on some of these. I have sent the Debian Security Team a proposal for making formal DPL delegates out of its members; it seems a ripe for updating the team's membership roster, as I understand some of its personnel have been inactive for a while. This leads us to the second problem. In my platforms for Project Leader, I asserted that a lack of transparency and visibility of process was a bad thing. I suspect, given what I know from conversation with some of the principals close to the infrastructure involved in getting our stable security updates out, that that's what we're dealing with. There have been technical failures and communication failures, with the former greatly exacerbated by the latter. I have asked Andreas Barth to look into this situation and establish as clear a factual record as he can. Using this report, we should be able to attack the areas of weakness. One thing I'd like to see is better documentation of the internal workings of the security update process, perhaps in the Debian Developers' Reference. With a broader understanding of security workflow, I'm hopeful that people will be less likely to draw erroneous inferences about what the causes of problems are, and more likely to make offers of assistance that prove fruitful. I expect to spend a lot of time talking about this issue to Debian developers and representatives of our user community (including sponsors) at DebConf 5, the 6th annual conference of Debian Developers, held from the 10th to the 17th of this month in Helsinki, Finland. Many people have stepped forward in public or in private to offer us assistance with ensuring that this problem does not recur, and that Debian upholds its valuable reputation as a consistent provider of timely security updates to its users. I regret the interruption of this service, but with so many people determined to apply their skills to this facet of our responsibilities, I'm confident that we can prevent its recurrence. > I have to admit that I definitely expected a word from our leaders what > they did to fix the short term problem and what they want to do for the > future to have fallbacks for all critical positions in our organisation. The leadership wasn't in a position to fix the short term problem without doing something terribly disruptive, like dismissing people such as Ryan Murray or Joey Schulze from their positions. Which aren't formally delegated in the first place, so they'd probably argue that the DPL has no authority to dismiss them, etc. I think it would just have created a lot of acrimony. The short-term problems are resolved (or so I'm told), and I have sent messages regarding delegation to three teams: Security, FTP Master, and System Administration. > Please lets come together and use the chance to discuss in real live > which might be more useful than e-mail or irc. If there would be > problems in the schedule I would offer my latex-beamer BOF session and > also offer to take over moderation of this kind of session. I wouldn't at all mind having a session like this, perhaps in addition to a "DPL grievance" BOF in one of the free slots. I.e., "bring your grievances to the DPL". I'm ready to sit in front of the assembled developers and hear their gripes. I've toyed with the idea of volunteering to do this for that empty first slot on the schedule, but part of me says we might set kind of an odd tone for the conference that way. At the same time I don't want to create the impression that I'm trying to avoid our problems. I'd rather meet them head-on. So, I'm torn. What do you guys think? -- G. Branden Robinson Debian Project Leader leader@debian.org http://people.debian.org/~branden/
Attachment:
signature.asc
Description: Digital signature