I did some investigation on who is frequently posting
on our mailing lists. I now created graphs until
end of last year and write a short summary for
those lists I regard worth a comment. I'm not
CCed to all of this list so if you want to discuss
something please keep me in CC. If you want to
discuss the results in general just write to debian-project.
All graphs and the code that was used to create the
graphs are available at
Ups, the graph becomes quite sparse in the last years. I can
not really imagine that the reason should be that our software
became more secure. Is anybody out there who has an explanation
which does not come to the conclusion that we immediately should
try to strengthen this team?
The traffic statistic is consistent with the activists graph:
Re: Yet another list statistics for debian-security
* Andreas Tille:
> Ups, the graph becomes quite sparse in the last years. I can
> not really imagine that the reason should be that our software
> became more secure. Is anybody out there who has an explanation
> which does not come to the conclusion that we immediately should
> try to strengthen this team?
Well, this is a general discussion list, not used for team
coordination. As a result, if our documentation and tools improve,
and the quality of our security support, traffic on the list should
decrease, and not increase. Therefore, I don't see a reason to worry,
at least not based on the numbers you presented. (On top of that,
much of the 2008 list traffic is probably related to the broken random
number generated, but I haven't checked this.)
Regarding team load, it's true that there's quite a backlog in terms
of known issues (see, for instance,
but due to communication overhead etc., we'd need to add a ridiculous
number of people to the team to make a dent in it--if all the work is
done inside the team.
As the security team, we generally try to react in a reasonable time
frame to patch submissions (that is, debdiffs for a proposed upload to
stable-security or testing-security, and a short test report).
However, for quite a few issues, there's little activity from package
maintainers. If nobody in the security team uses the package on
production systems, and the package maintainer cannot provide input,
providing a security update is indeed difficult.