There are two factors here pushing in opposite ways:<br><br>(A) -> the speed of getting security bugs fixed / reviewed / commited.<br>(B) -> the speed that BZ installation admins can tolerate in trying out and installing new versions.<br>
<br>Firefox has a very fast (B), because:<br><br>-> it has an auto-updater.<br>-> it's client sofware.<br><br>Bugzilla has a much slower (B), because:<br><br>-> it doesn't have an auto-updater.<br>-> it's server software.<br>
-> an upgrade impacts the entire organization, not just one user.<br><br>So while the code HEAD in our version-control system is a great way to iterate, our end-users have a much slower (B) compared to the (B)'s of other MoFo products (Firefox included).<br>
<br>You want to avoid regressions by having only one security fix per release. While this would work great in environments where you have a fast (B), I'm afraid it would suck for Bugzilla (for the reasons above).<br><br>
The way to avoid regressions with a slow (B) is to have better QA, not to increase release cycles to a rate which users can't keep up with, especially since we can't vouch for our releases' regressions.<br><br>
<br><div class="gmail_quote">On Sat, Feb 7, 2009 at 6:57 AM, Max Kanat-Alexander <span dir="ltr"><<a href="mailto:mkanat@bugzilla.org">mkanat@bugzilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, 4 Feb 2009 16:43:31 -0600 Reed Loden <<a href="mailto:reed@reedloden.com">reed@reedloden.com</a>> wrote:<br>
> If there are critical security<br>
> bugs that need to get fixed, they should get fixed ASAP and not depend<br>
> on waiting until some future release.<br>
<br>
</div>        I agree, that's why we should release as soon as we have a<br>
security patch. We didn't have to fix both issues in one release.<br>
<div class="Ih2E3d"><br>
> You shouldn't be risking users<br>
> just because you don't want Bugzilla to look bad that it has to<br>
> release twice within 24 hours.<br>
<br>
</div>        I assume you meant that we shouldn't be putting users at risk,<br>
and I understand that, and I agree. We shouldn't be putting users at<br>
risk. In this case, we put users far more at risk by releasing multiple<br>
invasive patches on a stable branch without any time for live testing.<br>
<br>
        There are other risks than just security risks--risks far more<br>
common. The risk of lost productivity, the risk of data loss, the risk<br>
of critical bugs that make a product unusable. We shouldn't be placing<br>
users at risk of those things, and as we include more invasive patches<br>
in one stable release without live testing, those risks dramatically<br>
multiply.<br>
<br>
> If this same policy was applied to Firefox [snip]<br>
<br>
        Although I think that what I said above is enough, and that I<br>
do understand what you're saying here, since this has been coming up<br>
more and more, I'd like to take this opportunity to point this out:<br>
<br>
        Firefox and Bugzilla are not comparable products. The only<br>
thing they have in common is that they are both software, and they are<br>
both open-source. Firefox has numerous paid developers, an entire<br>
funded organization, and numerous highly involved QA tests and<br>
procedures. Firefox has an auto-updater.<br>
<br>
        Bugzilla has zero full-time developers, none of whom are paid<br>
in any way. It has exactly two people who spend a significant amount of<br>
their time on it (myself and LpSolit), and a small community of<br>
additional contributors and active reviewers (who, by the way, are<br>
extremely appreciated, and I wish that we had more and more people who<br>
contributed and reviewed!). Our IT team essentially consists of me and<br>
some time from Mozilla IT that Community Giving is gracious enough to<br>
pay for. Our release team currently consists of just me.<br>
<br>
        Although I'd love to have a real funded organization behind<br>
Bugzilla, and maybe some day we will, in the present moment we have to<br>
adopt policies that work for our environment, and that is an<br>
environment of *limited resources*. Having limited resources means that<br>
we must accept and understand our limited capabilities, and adapt<br>
ourselves in ways that we can still produce a quality product within<br>
those constraints.<br>
<br>
        I proposed these policies because they work within those<br>
limited constraints, not because I believe they are the best policies<br>
any project can adopt. They will work to prevent similar situations as<br>
our recent one, in the future, and that is what I am most concerned<br>
about.<br>
<br>
        What happened was extremely dangerous, both to our users and<br>
to us as a project, and we have to not just handle the dangerous<br>
situation (as we did), but also make sure that we adopt firm solutions<br>
that will prevent the same situation from recurring in the future.<br>
<div class="Ih2E3d"><br>
        -Max<br>
--<br>
<a href="http://www.everythingsolved.com/" target="_blank">http://www.everythingsolved.com/</a><br>
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.<br>
-<br>
</div><div><div></div><div class="Wj3C7c">To view or change your list settings, click here:<br>
<<a href="http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd@bugzilla.org" target="_blank">http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd@bugzilla.org</a>><br>
</div></div></blockquote></div><br>