We discussed the pros and cons of adding a Beta to the Firefox 3 schedule at last week's development [1] and product delivery [2] meetings, and then had a follow up call with representatives from the build, QA, and development teams to review the commentary and discussion and come back with a proposal.
// Proposal
After that discussion, the decision was to propose that we add a third beta milestone for Firefox 3.1, as well as a requirement that by Thursday, December 4th, all component owners re-triage their blocker lists in order to identify which require beta exposure, and also to develop estimates for driving those lists to zero. From here forward we will focus on blocker numbers at our weekly meetings, requiring component leads to present plans for reducing the numbers over time to ensure we're trending in the right direction. We believe that we can add this milestone without a major impact on the shipping schedule for the release.
// Rationale
We don't have full clarity into the nature of our remaining blockers, some of which likely require beta exposure. In order to close this release, a re-triaging (like we did around Firefox 3 Beta 4) is required both to identify the severity of the remaining blockers and the time required to address them properly. Further, the impact of late Beta 2 landings such as Private Browsing Mode, Worker Threads, Speculative Parsing and TraceMonkey will benefit from multiple beta releases.
The insertion of another beta also offers another public consultation point for web and add-on developers, allowing us to react to their feedback. Again, with wide-reaching changes like those listed above, it was felt that this was prudent, especially if it could be done without major impact to schedule.
Finally, as mentioned during the meetings last week, since we will be holding off from any additional changes that would affect themers and add-on developers, this gives our add-ons community a full beta cycle to test and update their add-ons. The hope is that when Beta 3 is released, compatibility with our existing add-ons will be high, encouraging more users to shift to the beta to provide their usage feedback.
// Process
* Only patches for blocker bugs and those with explicit approval will be accepted into the Gecko 1.9.1 / Firefox 3.1 codebase (initially to be on the mozilla-central repository, soon to be branched to the mozilla-1.9.1 repository).
* Component leads will re-triage their blocking bugs marking those requiring Beta exposure as "P1", and those required for release as "P2"; any other priority will imply that the blocker is a significant issue but one which should only get attention if the P1s and P2s aren't being actively worked. This is to be completed by Thursday, December 4th.
* Regular triage meetings will be held to process outstanding blocker nominations and approval requests. At the weekly development meetings the blocker fix rates and acceptance rates will be presented & discussed to ensure we keep an eye on progress.
* No new features will be accepted into Beta 3. Limited string changes will be accepted. No add-on compatibility changes will be accepted.
* Beta 3 code freeze will be scheduled based on the results of the triage, but is expected to be in early January 2009.
// Discussion
Please discuss the aspects of this proposal on this thread (follow-up to dev.planning). We will also discuss it during today's development meeting at 11am PST (see https://wiki.mozilla.org/Platform/2008-11-25 for details).
We still want to make the promise to add-ons developers that beta2 will be "stable enough" to start mass converting add-ons, and your email does mention this.
It follows in my mind that by making this statement we're committing to keep major functionality after beta2. For example, it would be bad if someone wants to take advantage of DOM worker threads in their add-on, and we pull it before beta3.
I just want to call this out as something that's an implicit promise we're making. If we're not ready to make that promise we should make sure we say so.
Mike Beltzner wrote: > * No new features will be accepted into Beta 3. Limited string changes > will be accepted. No add-on compatibility changes will be accepted.
For what it's worth, I have some changes that still need to happen to the tab drag/drop stuff that are technically add-on compat changes (in that they change the notifications add-ons see), but are actually aiming to reduce the bar for add-ons working correctly. Would those be accepted for beta 3? The current notifications are just wildly wrong when a page that's still loading is dragged to a different window.
On 25-Nov-08, at 11:06 AM, Christopher Blizzard wrote:
> We still want to make the promise to add-ons developers that beta2 > will be "stable enough" to start mass converting add-ons, and your > email does mention this.
Yes, this is an important plank of both the rationale and the process!
> It follows in my mind that by making this statement we're committing > to keep major functionality after beta2. For example, it would be bad > if someone wants to take advantage of DOM worker threads in their > add-on, and we pull it before beta3.
Part of the Beta 2 criteria was that anything that made it into that beta was being accepted as our set of technologies to ship in Firefox 3.1. I concur that we're making this implicit promise, and will make sure that's a point drawn clearly on the call.
Of course, if it turns out that worker threads puts our overall release at risk, or introduces massive-scope security problems, etc, we might have to re-evaluate. We're never going to ship something unless it's ready. However, because we're making a commitment to our add-on developers, it wouldn't be removed lightly or without evaluating alternatives.
> I just want to call this out as something that's an implicit promise > we're making. If we're not ready to make that promise we should make > sure we say so.
This is a little tricky, as I don't want to walk down the route where we're making platform-promises to anyone. Firefox is the product that's driving here, and we'll do what's best for Firefox. Wherever possible we will do things to work with and make things easier for our add-on community, but we can't get into a position where we limit our ability to make required changes to the codebase in order to serve that portion of our community. I'm perhaps focusing on a semantic nit here (about what "required") means, and indeed it would have to be a pretty major issue to appear at this point to make us change course, but I don't want to make blanket promises that handcuff us, either.
> Mike Beltzner wrote: >> * No new features will be accepted into Beta 3. Limited string >> changes will be accepted. No add-on compatibility changes will be >> accepted.
> For what it's worth, I have some changes that still need to happen > to the tab drag/drop stuff that are technically add-on compat > changes (in that they change the notifications add-ons see), but are > actually aiming to reduce the bar for add-ons working correctly. > Would those be accepted for beta 3? The current notifications are > just wildly wrong when a page that's still loading is dragged to a > different window.
It depends. If I were an add-on developer, and I started building my add-on one way, would that still work after these changes? That's what I'd consider "compatibility". Improvements will always be accepted. :)
Mike Beltzner wrote: >> For what it's worth, I have some changes that still need to happen to >> the tab drag/drop stuff that are technically add-on compat changes (in >> that they change the notifications add-ons see), but are actually >> aiming to reduce the bar for add-ons working correctly. Would those >> be accepted for beta 3? The current notifications are just wildly >> wrong when a page that's still loading is dragged to a different window.
> It depends. If I were an add-on developer, and I started building my > add-on one way, would that still work after these changes?
That really depends on how invasive your add-on was, what assumptions it made, and how much it tried to work around the existing bugginess.
Put another way, any change in the event sequence add-ons see is a potential add-on failure point if add-ons make enough assumptions.
I think in this case add-ons that don't make boneheaded assumptions will still work after these changes, and the number of addons that don't make boneheaded assumptions and still work will increase.
>> Mike Beltzner wrote: >>> * No new features will be accepted into Beta 3. Limited string >>> changes will be accepted. No add-on compatibility changes will be >>> accepted.
>> For what it's worth, I have some changes that still need to happen >> to the tab drag/drop stuff that are technically add-on compat >> changes (in that they change the notifications add-ons see), but >> are actually aiming to reduce the bar for add-ons working >> correctly. Would those be accepted for beta 3? The current >> notifications are just wildly wrong when a page that's still >> loading is dragged to a different window.
> It depends. If I were an add-on developer, and I started building my > add-on one way, would that still work after these changes? That's > what I'd consider "compatibility". Improvements will always be > accepted. :)
I think that if the current way is broken, and this enables a more stable and reliable addon, we should tell addon authors that this specific piece needs work, and b2 should not be their target for that specific functionality. If the implementation of a new feature is flawed, we should tell addon authors that we're fixing it and just do it, rather than ship a substandard impl. This would obviously need to be done by b3, of course.
Christopher Blizzard wrote: > Mike, thanks for the mail.
> We still want to make the promise to add-ons developers that beta2 > will be "stable enough" to start mass converting add-ons, and your > email does mention this.
But what if extensions don't work with 3.1b2? I can't get many good things to happen with -chrome <chromeurl> based extensions.
<johnjbar...@johnjbarton.com> wrote: > Christopher Blizzard wrote:
>> Mike, thanks for the mail.
>> We still want to make the promise to add-ons developers that beta2 >> will be "stable enough" to start mass converting add-ons, and your >> email does mention this.
> But what if extensions don't work with 3.1b2? I can't get many good things > to happen with -chrome <chromeurl> based extensions.
Do they work with 3.1b1? With 3.0.x? Bug numbers? Test cases?
Mike Shaver wrote: > On Tue, Nov 25, 2008 at 7:21 PM, John J Barton > <johnjbar...@johnjbarton.com> wrote: >> Christopher Blizzard wrote: >>> Mike, thanks for the mail.
>>> We still want to make the promise to add-ons developers that beta2 >>> will be "stable enough" to start mass converting add-ons, and your >>> email does mention this. >> But what if extensions don't work with 3.1b2? I can't get many good things >> to happen with -chrome <chromeurl> based extensions.
> Do they work with 3.1b1? With 3.0.x? Bug numbers? Test cases?
