Avoiding Future Security Bug Regressions

[Max Kanat-Alexander]

	We've seen several regressions from the security bugs that were
fixed in 3.2.1, 3.0.7, 2.22.7, and 3.3.2.

	I see two causes for this:

	1) Many invasive security security bugs were checked in at
	   once immediately before a release.

	2) We did not release our point releases quickly enough after
	   each individual security bug was fixed, so many bugs were
	   fixed in a single release.

	In order to avoid future regressions of a similar nature, I am
proposing the following re-organization of the release process:

	1) Once any security bug is fixed, we should try to release
	   within the month. We should generally not put a security
	   release on hold for other security patches or other bug
	   fixes.

	And the following policies:

	1) No matter what, no more than one *invasive* security patch
	   per release.

	2) All invasive security patches should be tested on
	   bugzilla.mozilla.org for at least 24 hours before a release.

	An example of an invasive security patch would be the
attachment patch we just did, or the fixing of the process_bug CSRF
that we just did. 

	If there is no objection, I will write these up on the
Wiki and they will become the official policy of the Bugzilla
Project by Wednesday of next week.

	Sound good?

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.