Bill Allombert wrote: > The Vancouver plan has several mention of the security team which lead > to believe it was accomodated to address the concern of this team. > However <20050316115031.GC5330@finlandia.infodrom.north.de> shows that > the security team was not consulted and the most active security officer > does not endorse the plan, and has no problem suporting 20 architectures > security-wise. Er, let's quote every mention of "security" in Steve's mail: joey@dragon:~>wget -q -O - http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html | grep -i security | sed 's/^/# /' | re-add-some-missing context | manual-annotations 3< /dev/joey/brain # update, deploying the testing-security queues has been held up # queues for testing-security. This week, Andreas Barth and Ryan Murray # to handle the addition of testing-security queues. Once this happens, # the testing-security configuration should itself be completed for all # architectures in quick succession, with the result that testing-security All of the above refers only to the testing-security queue for sarge. AFAIK the only involvment of the security team with that queue is that they require said queue to exist at release time so they can easily "support 20 architectures". Anyway, no mentions of the security team yet. # The reality is that keeping eleven # architectures in a releasable state has been a major source of work for # the release team, the d-i team, and the kernel team over the past year; # not to mention the time spent by the DSA/buildd admins and the security # team. First mention of the security team. It's a bit strange that it mentions testing being a source of work for the security team, who after all do security for stable, but it could well be referring to any of these activities: - coordination with buildd admins and RMs about the upcoming release, buildd setup for testing-security, etc - contacting maintainers to get package fixes in unstable - coordinating security releases with unstable getting fixed to (to some degree; most recent DSAs have included a note about the fix in unstable as well as testing) It's not clear to me how much of this has to do with the number of architectures though. Another possibility might be that it's referring to the testing security team. We have indeed (and as expected) seen that autobuild issues tend to make it hard to get security fixes into testing in a timely manner. So perhaps this refers to that team. Or some combination of the two teams. Yet another possibility of course is that the four words "and the security team" were added to the draft for whatever reason and escaped the notice of everyone who reviewed the document because we didn't expect it to be subject to this kind of rather useless deconstruction. # They will be released with sarge, with all that # implies (including security support until sarge is archived), but they Nothing new here, only relevance to the security team is that it's that team's mission to provide said support to Debian releases. # - the Security Team must be willing to provide long-term support for # the architecture Second and final mention of the security team. Gives them some veto power over release architectures. Doesn't seem to me to imply that they were consulted and asked for this power; instead it seems like a fairly common sense requirement similar to the requirement that a release architecture "must have a working, tested installer". After all, if the security team can't support a stable release, Debian should not be calling it stable. I'm left with just the one mention of the security team that seems to imply they've had to do a lot of work keeping the eleven arches in sarge in a relesable state, and that mention seems a fairly shakey foundation to base an assumption that the document was crafted to appear to include concerns of the security team and that DPL candidates who signed it were somehow lax in not checking this.. > Did you sign on the assumption it has been reviewed by the security team, > or did you know they had not been consulted ? Did you make some > investigations ? > > Ftp-master and release team are well within their right to issue their > proposed plan without consulting others team. However, you signed in > your quality of DPL-candidate and the DPL role is to get advice from > relevant parties before endorsing a plan. I'd be happy to see the DPL candidates answer these questions, but the assumption behind them seems to be on shakey ground from my reading of the document. -- see shy jo  See any of my periodic posts to debian-release about "sarge security status".  Which is a rather sly insinuation that I'd hate to have to think was the main reason for Bill's mail.
Description: Digital signature