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.
> 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.
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.
> > 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.
> 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
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.
> 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. > 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
Why is the cited bug blocking anyway? Seems like it's an enhancement and TM could be shipped without it.
> On 19.02.2009 20:05, L. David Baron wrote: >> 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.
>> 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
> Why is the cited bug blocking anyway? > Seems like it's an enhancement and TM could be shipped without it.
