Avoiding Future Security Bug Regressions

[Max Kanat-Alexander]

On Wed, 4 Feb 2009 16:43:31 -0600 Reed Loden <reed at reedloden.com> wrote:
> If there are critical security
> bugs that need to get fixed, they should get fixed ASAP and not depend
> on waiting until some future release.

	I agree, that's why we should release as soon as we have a
security patch. We didn't have to fix both issues in one release.

> You shouldn't be risking users
> just because you don't want Bugzilla to look bad that it has to
> release twice within 24 hours.

	I assume you meant that we shouldn't be putting users at risk,
and I understand that, and I agree. We shouldn't be putting users at
risk. In this case, we put users far more at risk by releasing multiple
invasive patches on a stable branch without any time for live testing.

	There are other risks than just security risks--risks far more
common. The risk of lost productivity, the risk of data loss, the risk
of critical bugs that make a product unusable. We shouldn't be placing
users at risk of those things, and as we include more invasive patches
in one stable release without live testing, those risks dramatically
multiply.

> If this same policy was applied to Firefox [snip]

	Although I think that what I said above is enough, and that I
do understand what you're saying here, since this has been coming up
more and more, I'd like to take this opportunity to point this out:

	Firefox and Bugzilla are not comparable products. The only
thing they have in common is that they are both software, and they are
both open-source. Firefox has numerous paid developers, an entire
funded organization, and numerous highly involved QA tests and
procedures. Firefox has an auto-updater.

	Bugzilla has zero full-time developers, none of whom are paid
in any way. It has exactly two people who spend a significant amount of
their time on it (myself and LpSolit), and a small community of
additional contributors and active reviewers (who, by the way, are
extremely appreciated, and I wish that we had more and more people who
contributed and reviewed!). Our IT team essentially consists of me and
some time from Mozilla IT that Community Giving is gracious enough to
pay for. Our release team currently consists of just me.

	Although I'd love to have a real funded organization behind
Bugzilla, and maybe some day we will, in the present moment we have to
adopt policies that work for our environment, and that is an
environment of *limited resources*. Having limited resources means that
we must accept and understand our limited capabilities, and adapt
ourselves in ways that we can still produce a quality product within
those constraints.

	I proposed these policies because they work within those
limited constraints, not because I believe they are the best policies
any project can adopt. They will work to prevent similar situations as
our recent one, in the future, and that is what I am most concerned
about.

	What happened was extremely dangerous, both to our users and
to us as a project, and we have to not just handle the dangerous
situation (as we did), but also make sure that we adopt firm solutions
that will prevent the same situation from recurring in the future.

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