So currently our plan for Firefox 3.1 beta 3 seems (based on my
asking questions on IRC) to be to ship it about a week after
https://bugzilla.mozilla.org/show_bug.cgi?id=upvar2 lands.  We don't
seem to have any deadline for that.

I'm wondering how long we're willing to wait.  It seems to me that:

  (1) without Tracemonkey, we probably could have shipped 3.1
  (final) by now (or, if not now, within the next month), since
  other areas would have been under more pressure to finish sooner,
  and since some of the things we've been adding to the blocker list
  lately (in Layout, anyway) feel a lot more like 3.1.0.2 blockers
  than 3.1 blockers.

  (2) Our 3.1 release is currently slipping well into the gap
  between when we were expecting to ship 3.1 and ship 3.2.

I think there should be a limit to the amount we're willing to slip
3.1 to accomodate tracemonkey, and I think we should decide what
that limit is.

If the limit is more than a month out, I think we should consider
inserting an additional beta (to get testing on everything that's
landed since beta 2, which was over 2 months ago) and bumping most
of the current P1 blockers to blocks-last-beta blockers.

If there truly isn't a limit, then I think we're too early in the
cycle to be in a feature freeze, and we should open 3.1 up to new
features.  

But I think there really should be a limit:  I don't see why
Tracemonkey shipping for the first time in Firefox 3.1 in November
2009 is any better than Tracemonkey shipping for the first time in
Firefox 3.2 in November 2009, and I think we have a lot of other
good work in 3.1 that we should be getting into the hands of our
users.

-David

--
L. David Baron                                 http://dbaron.org/

On 19/02/09 11:05 AM, L. David Baron wrote:

Yeah, I have to concur here. Tracemonkey is really cool tech, and a
remarkably quick initial development, but it's not the whole enchilada
of the browser. There's no need to *remove* it -- it is certainly
getting much more stable and fast -- but it feels reasonable to think
about a 3.1 with TM turned off by default. Adventureous users can turn
it on, and we can turn it right back on by default on the trunk / 3.2
alpha work. Releases require compromise-logic, and there's good stuff in
3.1 being blocked by TM. Stuff that has strategic long-term implications
for web content.

It's not like we need significantly more public testing to *find* bugs
in TM. There's a substantial list with a pretty constant input-rate from
nightly testers, lots for the group to work on. A lot of those are
serious bugs, regularly nightly topcrashers and such.

-Graydon

On Feb 19, 5:17 pm, Graydon Hoare <gray...@mozilla.com> wrote:

The only reason I would have for suggesting that TM not be turned off
for 3.1 is that it's already on in b2 and has been promoted quite
heavily as a key 3.1 feature. Wouldn't be the greatest PR move in the
world. On the other hand, I'm loathe to suggest that PR get in the way
of any technical decisions.

Personally, I think a third beta would be better received than a TM-
less 3.1 release. FWIW.

On 19.02.2009 20:05, L. David Baron wrote:

Why is the cited bug blocking anyway?
Seems like it's an enhancement and TM could be shipped without it.

dao

As can be seen from the bugs that it blocks, it fixes correctness
issues as well as performance ones.

More about how we move forward with 3.1 soon.

Mike

On 2/21/09, Dao <d...@design-noir.de> wrote:

--
Sent from Gmail for mobile | mobile.google.com