Postponing the Firefox 3.6.x → 7.0 advertised update
The previously scheduled 3.6 → 7.0.1 advertised update is now postponed while we make sure our server capacity is sufficient for release. Once the investigation is complete I will communicate a new date well in advance so all stakeholders can plan accordingly.
I apologize for any churn this may have caused.
Reminder: Firefox 3.6.23 → 7.0.1 advertised update scheduled for Thursday
Just a friendly reminder that we are planning to offer the Firefox 3.6.23 → 7.0.1 advertised update this Thursday, 2011-10-6.
What does the advertised update mean?
- We will be offering an advertised update (also sometimes called a "major update") for Firefox 3.6.x -> Firefox 7.0 on 2011-10-06 (1 week and 2 days after Firefox 7's release)
- The advertised update has no bearing on support levels. It does not mean Firefox 3.6 is end-of-life
- The advertised update has no bearing on the Firefox ESR proposal
- This is part of the old release process and is unchanged from what we have been doing for the past 3+ years
- The prompt is opt-in...if users decline, they stay on 3.6.x and get security updates until the next time we decide to prompt
- We did this for 3.0.x -> 3.5, 3.5.x -> 3.6, 3.6.x -> 4.0 and 3.6.x -> 5.0...nothing new
- If enterprise deployments have advertised/"major" updates disabled in rollouts their users will not see the prompt but they will see Firefox 3.6.24 when it is released on 2011-11-08
This is mainly to move regular Firefox users who don't know there is an update up to a newer/better version if they are so inclined.
Based on previous advertised update offers we expect to see a significant percentage of users installing the new version. We are, of course, watching the data closely to see what happens and to make sure there are no unexpected issues.
As always, feel free to contact me with any questions or concerns.
Code freeze for Firefox 3.6.18 is MONDAY (2011-06-06) @ 11:59 pm PDT
I know we've been all been focused on the future releases but I'd like to call attention to Firefox 3.6.18.
Code freeze for Firefox 3.6.18 is THIS MONDAY (2011-06-06) @ 11:59 pm PDT!
If you have a bug in the blocking list, you are on the hook to have it done (or let branch-triage@mozilla.org know why it can't be done).
Thanks!
Important dates for the Firefox rapid release process
This has come up on assorted mailing lists so I figured I'd blog about it...
Please do note the rapid release process is still new and might need to be adjusted as we go through a couple.
If you are.....
A Developer
- You need to focus on the fact that the next merge from mozilla-central to mozilla-aurora is 2011-05-24 (any code for Firefox 6 needs to be in by that date)
- You need to know any major issues you find in code landed before 2011-04-12 should be brought to the attention of release drivers to put into beta or aurora, wherever is appropriate
A Localizer
- You need to focus on the fact that you only have until 2011-05-17 to finish localizing Firefox 5 content in mozilla-aurora (time left for current work)
- You need to focus on the fact that the next merge from mozilla-central to mozilla-aurora is 2011-05-24 (time the work for the next cycle starts so you can plan)
Add-on Developer
- You only have until 2011-05-17 to test your add-on with Firefox 5 content in mozilla-aurora and mark your add-on as 5.0* compatible.
You will be able to test for 6 more weeks on beta but our beta audience has over 2 million people...you probably don't want to field their support questions and should just focus on getting it compatible during the aurora timeframe.
- You should start testing your add-on with Firefox 6 content in mozilla-aurora on 2011-05-24. You will have 6 weeks to test on aurora and another 6 weeks to test on beta
Anyone Else
- Firefox 5 will be released on 2011-06-21
I hear there is a developer calendar somewhere and intend to add the assorted merge dates. I have also been saying it every week in the platform, MoCo, channel, and product meetings. We're working on getting it added to the wiki in the appropriate places (thanks to Matt Brubeck for adding it on the RapidRelease wiki page).
Additionally, there are dates in the specifics document as well as a quick python program to spit out your very own merge schedule. Please note we are still working out the mechanics of merges so they may be +- a day or so.
mozilla-central to mozilla-aurora merge tomorrow, 2011-04-12
The merge from mozilla-central to mozilla-aurora happening TOMORROW (2011-04-12) at ~6:00 am PDT.
There is some discussion as to what "merge on 2011-04-12" means. It is generally open to two interpretations:
- Developers can land fixes up to 11:59 pm PDT on 2011-04-12 and the actual merge will happen on 2011-04-13 PDT
- Developers can land fixes up to the merge point, which happens sometime on 2011-04-12
We are going with #2 above and intend to do the merge @ ~6:00 am PDT.
How will you know the merge is done / mozilla-central is tracking for Firefox 6 instead of 5?
There will be a version bump on mozilla-central to 6.0a1 (see bug 648653). Anything before that will generally be on track for the next Firefox version, anything after will likely wait for a future release.
What happens if the version bump hasn't happened and it is after 6:00 am PDT?
We've decided to give some more time, you can still land for the upcoming Firefox release (likely for < 24 hours).
Please use best judgement when pushing late tonight and tomorrow. We will NOT be closing the tree...normal mozilla-central tree rules apply.
Version numbers on mozilla-central changing next week
This is a heads up that mozilla-central will be bumped to the new versioning scheme early next week PDT. It will either be Monday (and bump to 5.0a1) or Tuesday (and bump to 6.0a1). Please see bug 648653 and the development specifics document for details.
Please comment in bug 648653 if there are urgent items that need to be taken care of before this happens or if there is a concrete reason Monday or Tuesday appears to work better.
Firefox 4 “softblocking” bugs no longer have automatic approval
Quick note about softblocking bugs:
- Blocking bugs marked [softblocker] (betaN or final) NO LONGER have automatic approval
- To land a softblocker on mozilla-central you can do one of the following:
If the risk / reward ratio is close to zero....
- Add justification to the bug
- Toggle the "approval2.0" flag on the patch to "?" (aka ask for approval on the patch itself)
-OR-
If you think the bug is wrongly categorized and needs to block the release of Firefox 4...
- Remove "[softblocker]" from the whiteboard
- Add justification to the bug
- Toggle the "blocking2.0" flag to "?" (aka nominate it for hardblocking)
- This means the ONLY bugs with automatic approval are hardblockers (betaN or final)
- We will be setting the "blocking2.0" flag to "-" shortly (aka making them not blocking)
- We will not be going through and removing [softblocker] from the whiteboard
Please let me know if you have any questions or concerns.
Blockers, softblockers, betas and you
Summary
- The betaN softblockers will be punted out of Firefox 4 very soon
- Please look over the betaN softblockers by THIS FRIDAY, 9:00 am PST, looking for bugs that should be upgraded to hardblocking status
- If you find a softblocker that needs to make Firefox 4, do the following:
- Remove "[softblocker]" from the whiteboard
- Add justification to the bug
- Toggle the "blocking2.0" flag to "?" (aka nominate it for blocking)
Details
The betaN softblockers are bugs that have been previously identified as:
- really nice to have for Firefox 4 but won't stop us from shipping (the "softblocking" part)
- needing beta coverage to make sure the fix is correct and doesn't cause new issues (the "betaN" part)
Regardless if beta 12 is the last beta, we are rapidly approaching the point where there will be no more betas. Once we freeze for the last beta, non-blocking bugs that require beta coverage are implicitly no longer approved.
We ask that interested developers make sure our soft/hardblocking and beta coverage decisions are sound before we freeze for the final Firefox 4 beta. Additionally, we understand that new information may have come to light (such as reproducibility, impact, etc) and want to make sure we are making decisions with the correct data.
Please take a moment to look over the betaN softblocker list by THIS FRIDAY, 9:00 am PST, looking for bugs that should be upgraded to hardblocking status.
If you find a softblocker that needs to make Firefox 4, do the following:
- Remove "[softblocker]" from the whiteboard
- Add justification to the bug
- Toggle the "blocking2.0" flag to "?" (aka nominate it for blocking)
To be warned, the bar for a hardblocker is extremely high at this point, especially for bugs that have been marked softblocking so long.
After this Friday at 9:00 am PST we reserve the right to remove the blocking status of the betaN softblockers (and thus automatic approval) at any time. Once we do so, approvals will be on a case-by-case basis.
Mozilla-central landings today and the beta 11 plan
As discussed in today's platform meeting and decided by drivers after reviewing current information, this is the plan for beta 11 and how it relates to mozilla-central development work.
Beta 11
We are pushing to get these bugs in by EOD today (PST):
If you are on the hook for any of those (including reviews and feedback) they are your number one priority.
If you are landing bugs NOT in that list, please think about the risk to beta 11. If anything is even slightly risky, please hold off a day until we branch for beta 11 before landing on mozilla-central. We will not close mozilla-central and instead trust developers to act responsibly with risk.
Once we have all / the the majority of the bugs in the query above we will call a build using the last green changeset.
Beta 12
The current plan is to build when the remaining betaN hardblockers are done. This is heavily dependent on fix and blocker creation rate. I will be doing some analysis to give people a possible date range, but as far as development is concerned everything is the same (fix as many betaN hardblockers as quickly as possible).
As usual, feel free to contact me on IRC or via email if there are questions/concerns.
Updated Firefox 4 beta plan
This is the updated beta plan as discussed in the Platform meeting earlier today. It is a modification of the previous plan based on current bug counts and fix rates. Please email me if you have any questions or concerns.
The Updated Beta Plan
- If all betaN hardblockers are done by this Friday afternoon PST (2011-01-28) we will build beta 11 at that time. This is essentially staying on the previously posted plan
- If on Friday there are remaining betaN hardblockers we will not build and instead defer the decision until Tuesday (2011-02-01)
- If all betaN hardblockers are done by next Tuesday afternoon PST (2011-02-01) we will build beta 11 at that time. There will be no planned beta 12
- If on Tuesday there are remaining betaN hardblockers we will make a judgement call
- If on Tuesday the remaining betaN hardblockers are on track to land before Friday (2011-02-04), we will not build on Tuesday and instead wait for Friday. There will be no planned beta 12
- If on Tuesday the remaining betaN hardblockers look at risk to land by Friday (2011-02-04) we will create beta 11 on Tuesday and plan on having a beta 12. Beta 12 will not have a fixed schedule and will instead be built when the remaining betaN hardblockers are at zero
Bug Fix Priorities
[risky] betaN hardblockers > betaN hardblockers > final hardblockers > betaN softblockers > final softblockers
Again, feel free to contact me with any questions or concerns.