Security release needed

[David Miller]

Jake wrote:
> Gervase Markham wrote:
> 
>> - There are significantly more bugs marked as blocking2.20+ than there
>>   are blocking2.18+, and we shouldn't do a Release Candidate unless the
>>   build is a release candidate, which means fixing them all
> 
> I think this is the most compelling reason. A "Release Candidate" 
> implies that if there are no major issues found, this will be the 
> release. In a perfect world, the only change from, for example, 1.0rc1 
> and 1.0 would be a version number. To have known bugs that we want fixed 
> before a release takes place seems backwards. Our criteria should be 
> only slightly lower for an rc as it is for a full blown release. I 
> understand that there's some "cool stuff" that wants to appear on the 
> trunk but can't because of the 2.20 freeze, but we also need to focus on 
> the task at hand (eg, getting the current release out the door).

OK, here's the deal.  After I went and looked, and did a little triage, 
there are exactly 4 bugs that are blocking 2.20 that are not also 
blocking 2.18.  That hardly constitutes "significantly more" when you 
consider we still have 7 bugs left that are blocking 2.18.  We still 
have to have all the 2.18 blockers done before we can release 2.18.  If 
the 2.20 blockers happen to also be taken care of by that time, we'll 
release 2.20rc1.  If they aren't, we'll release 2.19.2.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/