As David mentioned in his previous thread, we have been holding beta 3
on a handful of JS patches, chiefly "upvar"
(https://bugzilla.mozilla.org/show_bug.cgi?id=452498).  That patch is
getting close, but the continuing and great work on fixing other
final-release blockers means that we're accumulating a lot of changes
on the 1.9.1 stream that would benefit from wider feedback from our
beta testers.  To that end, we're going to wrap up beta 3 in the next
week regardless of upvar status; a 4th beta will follow approximately
6 weeks after, as a vehicle for more testing of tracemonkey, video,
places and other eagerly-awaited improvements as well as feedback from
beta 3.

(Contrary to some reports, this "upvar" patch is not being taken as a
performance win at this point, but primarily to improve correctness
and robustness.  It lays a foundation that we believe will give us
great performance opportunities in the future, which is wonderful, but
not what's motivating its priority at this point.)

Analysis of our crash stats and other feedback indicate that we're in
a good position with respect to stability and robustness, with key
areas easily identified and a good understanding of the work needed to
remedy remaining issues.  (If you're one of the developers churning
through those bugs every day, it's easy to be pessimistic about them,
of course, which is a trait I value in engineers. :) )

Please join the product delivery call today at 11 Pacific for more
discussion of this, and thanks to everyone for their great work on
FF3.1 so far -- it's shaping up to be a very worth successor to
Firefox 3!

Mike

You are not the first to suggest that, indeed!  I think we should
discuss exactly that, but in another thread and after we get beta3 out
the door. :)

Mike

Any chance of accepting new features that were originally intended for
1.9.2 given the addition of a 4th beta?

We are going to be extremely conservative here, using the criteria that we
use for non-blocker approvals. To get in, a feature will need to be:

 - complete: no follow up fixes or initial implimentations that commit us to
extending the schedule further
 - proven: patches with tests, security reviews and performance impact
analysis, baked on trunk for a good amount of time
 - valuable: we need to understand the benefit of taking the change, and why
it's needed for 3.1 instead of later
 - removable: backout-ready, if anything goes wrong

There are certain things which are tempting targets of opportunity, and I'm
happy to talk about them when people are done their work on the 120 blockers
that remain, but we should not consider this as a re-opening for new
features.

At least, as I understand things at this time :)

cheers,
mike

To add here, I think it's common understanding that we're keeping the
tree as string frozen as planned. Not sure if that's impacting the
features you're thinking about.

Axel

On 26.02.2009 2:36 Uhr, Mike Beltzner wrote:

On 25-Feb-09, at 6:13 PM, Axel Hecht wrote:

Yes, definitely. Any string modifications will have to be for features  
with obvious and proven value, and ideally will be ready to go within  
the first week of re-opening as to minimize impact to our ability to  
ship locales.

I'm going to send some email shortly with a proposed schedule. Still  
trying to get a handle on what section of the P2s blockers we want to  
get in for Beta 3 code freeze.

cheers,
mike

On 2/25/09 5:05 PM, RyanVM wrote:
Given our near in-ability to get the tree closed down for beta 3, I'd
say no.  I really think that 3.1 ought to stay as feature frozen as
possible at this point.  I don't want to repeat this "inability to close
on a beta" business when we roll around to beta 4 and I think that new
features would exacerbate this problem.

All that said, I would like to know what the features you are proposing
we take so we can make a more informed case-by-case decision, but I
still think that the scope for anything we take would have to be pretty
small and the benefit would have to be pretty high for us to take it
this late in the game.

My two cents.

Clint