(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
- 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
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
Axel
> 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.
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
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