freebsd security - Aug 2015 - Is there a policy to delay & batch errata security alerts ?

Re. 8 Errata & Advisories since 
Fri, 14 Aug 2015 00:06:45 +0000 10.2-RELEASE announcement. eg
	Sender: owner-freebsd-announce at freebsd.org
	To: FreeBSD Errata Notices <errata-notices at freebsd.org>

Each release, a wave of alerts flood after.  The bigger the wave, the more
users will have insufficient time, & skip the lot.  Moving some
of the flood away from after release weeks would increase their security.

New bug alerts on new releases are OK immediately, but some alerts
seem perhaps existing issues delayed to check & also include latest
release, they add to the flood & could be alerted some earlier, some later ?

Presumably there's no delays eg for PR, giving longer quiet periods before
a release, slipping out bad news immediately after good.

What else might be causing batch flooding of alerts ?

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Reply after previous text, like a play - Not before, which looses context.
 Indent previous text with "> "         Insert new lines before 80
chars.
 Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64.
 Subsidise contraception V. Global warming, pollution, famine, migration.

On Sat, 29 Aug 2015, Julian H. Stacey wrote:
> Presumably there's no delays eg for PR, giving longer quiet periods
before
> a release, slipping out bad news immediately after good.
That seems highly unlikely.
> What else might be causing batch flooding of alerts ?
It's an awful lot of work to actually put all the pieces together to
release security advisories; batching reduces the workload for the team.
This is true no matter what project you look at, be it FreeBSD or MIT
Kerberos (where I am on the security team and can speak from personal
experience) or something else.  This is why errata notices are delayed
until they can go out with a security advisory; it's explicitly a way to
reduce the workload on the security team.

-Ben Kaduk