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[1], 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[1].
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[2] 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
[1] See any of my periodic posts to debian-release about "sarge security
status".
[2] Which is a rather sly insinuation that I'd hate to have to think
was the main reason for Bill's mail.
Attachment:
signature.asc
Description: Digital signature