Firefox 4 beta logistics
This is the current working Firefox 4 beta plan so you can plan accordingly. Feel free to email me directly with any questions.
Summary
- We'll take the most recent green changeset from mozilla-central this Friday, 2011-01-21 at 2:00 pm PST and call that beta 10
- The tree will close for < 15 minutes for this (if at all)
- We'll freeze nightly updates at or around the changeset we branched from (likely only for the weekend)
- Any problems with the beta will be dealt with on the relbranch
- We will release beta 10 as soon as possible during the week of the 24th
- We'll take the most recent green changeset from mozilla-cental on Friday, 2011-01-28 at 2:00 pm PST (or sooner if the remaining betaN hardblockers are finished) and call that beta 11
- The tree will close for < 15 minutes for this (if at all)
- We'll freeze nightly updates at or around the changeset we branched from (likely only for the weekend)
- Any problems with the beta will be dealt with on the relbranch
- We will release beta 11 as soon as possible during the week of the 31st
Details
Both frontend and platform managers have determined that their betaN hardblockers will not all be finished by this Friday. Additionally, greater than 318 bugs have been marked fixed since beta 9. We need beta coverage for most of those fixes but also need beta coverage for the remaining betaN hardblockers. To control risk for the RC the plan is to do two betas (10 and 11) rather than hold beta 10 for all betaN hardblockers. This will give us a week of beta coverage for the 318 bug fixes while still allowing beta coverage for the remaining betaN hardblockers.
Code freeze for beta 10 and 11 will also be a bit different. Previous betas closed the tree to stabilize and reduce beta risk. At this point in development, every day counts--we cannot shut down mozilla-central over the weekend as we have done before. Instead we'll freeze what's in the tree and run with it, dealing with any beta issues on the relbranch. Instead of metering what goes in before a freeze we will be driving to get as many fixes as possible so they can get more beta coverage.
To enable additional testing of the bits we intend to ship to beta while keeping the tree open for development, we will freeze mozilla-central nightlies to the changeset we branched from (likely only for the weekend). Developers can still use hourlies to test and will able to integrate their work with others without waiting a weekend for the tree to reopen.
For those curious, joduinn has provided the the specific plan for the nightly changeset freeze:
- RelEng will create a nightly ~2pm PST Friday, with same changeset as the beta10 builds
- RelEng will create the nightly build fri+sat+sun night as usual, but will force the updates to a hidden location. A human can download+install those nightly builds if they want (for regression ranges / reproduction), but no-one will get updated to these nightlies
- On Monday, release drivers will send the "ok to reenable normal nightly operation". RelEng will revert changes and trigger a mid-day Monday nightly so people on Friday afternoon nightly will directly update to Monday afternoon (skipping the fri/sat/sun night nightlies)
- We will then move snippets generated over weekend back to usual locations, and cleanup
- The change is a small, and we believe safe, change to how updates are created
Explicit Bug/Release Dependencies
- Beta 10: None, time-based release to test what we have done since beta 9
- Beta 11: BetaN hardblockers
- RC: Final hardblockers
I'll keep the various mailing lists and planet updated if anything changes. Again feel free to shoot me an email (or find me on IRC) with any questions you have.
Code freeze for Firefox 3.6.14 and 3.5.17 non-blocking bugs is TONIGHT
As posted in the schedule and discussed in various meetings, code freeze for Firefox 3.6.14 and 3.5.17 non-blocking bugs is tonight.
This freeze is for non-blocking bugs. Blocking bugs have an additional week.
If you have a bug that needs to land and don't have commit privs, please hop in #developers on irc.mozilla.org and ask someone else to push for you.
After today non-blocking patches will get their approvals recinded and will need to be renominated for a later release.
If there are any questions or concerns, please feel free to contact me in irc (LegNeato) or send an email (clegnitto@mozilla.com).
Firefox 4 beta 9 code freeze is TOMORROW
As mentioned in meetings (and planet via the meeting notes), the Firefox 4 beta 9 code freeze is tomorrow, 2011-01-07.
- If you have a risky change, don't land it until we've branched (likely Monday, 2011-01-10)
- If you need as much beta feedback as possible for a particular fix, please get it in for beta 9 if you can
- If you have a question, please ask instead of assuming (LegNeato on irc or clegnitto@mozilla.com)
Basically, think hard about your fixes and decide if you could reasonably justify the schedule slip if they cause problems. If you can't make that decision, feel free to ask me.
I don't anticipate giving the go for builds until Monday, late afternoon PST. In the early afternoon PST I will contact assorted stakeholders and see if there is anything that would hold the release and get an estimated time for the build.
Please let me know if there are any bugs you are worried about not making the freeze (and give justification why they can't wait until the next beta). A word of caution, the bar for blocking the freeze is extremely high.
Thanks!
GitHub AMQP integration service hook live!
As of last night you can now send AMQP messages to a message broker (like the one running on pulse.mozilla.org) for GitHub pushes and commits!
Here's how to set it up...
First, go to the admin area of one of your repositories:
Next click on "Service Hooks" on the left hand side:
After that, select the AMQP service hook:
Configure the hook to point at your server and it's done!
Once configured, the next time you push there will be messages sent via AMQP to your server from GitHub. Currently, it sends one overall push message containing all changeset info in the push as well as individual changeset messages.
Mesages are sent for the push with the following routing key format:
"github.push.#{owner}.#{repo}.#{ref}"
where:
owner = payload['repository']['owner']['name']
repo = payload['repository']['name']
ref = payload['ref_name']
Messages are also sent for each commit in a push, with the following routing key format:
"github.commit.#{owner}.#{repo}.#{ref}.#{author}"
where:
author = commit['author']['email']
(other fields are the same as above)
The message data is sent in JSON format.
Here's an example commit message (dumped from Python):
{u'_meta': {u'exchange': u'org.mozilla.exchange.pulse.test',
u'routing_key': u'github.commit.LegNeato.bztools.master.clegnitto@mozilla.com'},
u'payload': {u'author': {u'email': u'clegnitto@mozilla.com',
u'name': u'Christian Legnitto',
u'username': u'LegNeato'},
u'files': {u'added': [],
u'modified': [u'README.rst'],
u'removed': []},
u'id': u'4d69ae955e6f877000ecfe17def333b32973070b',
u'message': u'Change readme to point to my repo (and a test of AMQP GitHub service hook)',
u'timestamp': u'2010-11-22T15:16:26-08:00',
u'url': u'https://github.com/LegNeato/bztools/commit/4d69ae955e6f877000ecfe17def333b32973070b'}}
And here's an example push message (dumped from Python):
{u'_meta': {u'exchange': u'org.mozilla.exchange.pulse.test',
u'routing_key': u'github.push.LegNeato.bztools.master'},
u'payload': {u'after': u'0ccf64aa593e96a19529b9c9a3b1e0098c626108',
u'before': u'9aa20993159d5e714103abc6741b43feb371fc34',
u'commits': [{u'author': {u'email': u'clegnitto@mozilla.com',
u'name': u'Christian Legnitto',
u'username': u'LegNeato'},
u'files': {u'added': [],
u'modified': [u'bugzilla/models.py'],
u'removed': []},
u'id': u'80539c359d22ca35f61c34edb810bfc9c0bef6a8',
u'message': u'Add support for keywords',
u'timestamp': u'2010-11-17T16:14:37-08:00',
u'url': u'https://github.com/LegNeato/bztools/commit/80539c359d22ca35f61c34edb810bfc9c0bef6a8'},
{u'author': {u'email': u'clegnitto@mozilla.com',
u'name': u'Christian Legnitto',
u'username': u'LegNeato'},
u'files': {u'added': [],
u'modified': [u'README.rst'],
u'removed': []},
u'id': u'4d69ae955e6f877000ecfe17def333b32973070b',
u'message': u'Change readme to point to my repo (and a test of AMQP GitHub service hook)',
u'timestamp': u'2010-11-22T15:16:26-08:00',
u'url': u'https://github.com/LegNeato/bztools/commit/4d69ae955e6f877000ecfe17def333b32973070b'},
{u'author': {u'email': u'clegnitto@mozilla.com',
u'name': u'Christian Legnitto',
u'username': u'LegNeato'},
u'files': {u'added': [],
u'modified': [u'bugzilla/models.py'],
u'removed': []},
u'id': u'0ccf64aa593e96a19529b9c9a3b1e0098c626108',
u'message': u'Add some string representations',
u'timestamp': u'2010-11-22T18:19:32-08:00',
u'url': u'https://github.com/LegNeato/bztools/commit/0ccf64aa593e96a19529b9c9a3b1e0098c626108'}],
u'compare': u'https://github.com/LegNeato/bztools/compare/9aa2099...0ccf64a',
u'forced': False,
u'ref': u'refs/heads/master',
u'ref_name': u'master',
u'repository': {u'created_at': u'2010/11/15 14:45:56 -0800',
u'description': u'Models and scripts to access the Bugzilla REST API.',
u'fork': True,
u'forks': 0,
u'has_downloads': True,
u'has_issues': False,
u'has_wiki': True,
u'homepage': u'',
u'name': u'bztools',
u'open_issues': 0,
u'owner': {u'email': u'clegnitto@mozilla.com',
u'name': u'LegNeato'},
u'private': False,
u'pushed_at': u'2010/11/22 19:17:25 -0800',
u'url': u'https://github.com/LegNeato/bztools',
u'watchers': 2}}}
Now that this service exists Pulse can get messages about Mozilla checkins for projects hosted on GitHub, making Pulse the one-stop shop for real-time Mozilla data...once the Bugzilla extension, MediaWiki extension, and Mercurial extension are put into production of course.
Code freeze for Firefox 3.6.13 and 3.5.16 is TOMORROW
Just a friendly reminder that code freeze for Firefox 3.6.13 and 3.5.16 is tomorrow (Thursday, 2010-11-18) @ 11:59 pm PST. Here's where we currently stand:
Blocker report for Firefox 3.5.16 and 3.6.13 (as of 2010-11-17 16:32:53-08:00)
Overview
3.5.16
- blocking: 32
- fixed: 17
- open: 15
3.6.13
- blocking: 37
- fixed: 22
- open: 15
Open Blocker Assignees
Blake Kaplan: 3
Robert Sayre: 3
Mats Palmgren: 2
Josh Aas: 2
Steven Michaud: 2
Johnny Stenback: 1
Ms2ger: 1
Jason Orendorff: 1
Nicholas Nethercote [:njn]: 1
Igor Bukanov: 1
Two F-ing days for Firefox 3.6.12 and 3.5.15!
You may have noticed that we released Firefox 3.6.12 and 3.5.15. If you are running Firefox, please update! The release contains a single fix (read more about in the release notes). The fix addresses an issue relating to the Nobel prize website that has gotten a bit of coverage:
I wanted to share a little more detail about the release and Mozilla's response to the issue. I also wanted thanks those that made these releases happen quickly yet-again.
The (impressive) release schedule went like so:
- A new trojan was created on Sunday (based on the link date in the exe)
- Morten Kråkvik of Telenor SOC reported an exploit targeting particular versions of Firefox 3.6 on Windows XP that Telenor found while investigating an intrusion attempt on a customer network. The report came in on Monday night @ ~9:00pm PDT
- Many engineers were up investigating the issue all Monday night
- We had Google block the page serving the malware within a couple of hours on Monday night. They responded extremely quickly. Users visiting the known exploit site at that point were warned via Firefox's built-in Phishing and Malware Protection
- We sent the new malware to AV vendors and they had started working on signatures on Monday night PDT
- A fix to the underlying Firefox issue was found, reviewed, changed, re-reviewed, and landed on Tuesday for all branches
- Builds were created by Release Engineering Tuesday evening and QA confirmed the fix that night as well
- QA powered through tool and DNS issues to qualify the update Wednesday morning
- We released 2 fully localized products (3.5.15 & 3.6.12) on 3 platforms (Windows, Linux, Mac) with the fix Wednesday afternoon
That is less than 48 hours from the point Mozilla became aware of the issue to fixes available to end-users. WOW! What's even more amazing is there are places we can get even faster without sacrificing the stability our users come to expect.
Thanks to everyone for the late nights, hard work, and solid fixes!
(see this post for the title reference)
Tons of Mozilla/Firefox releases today
Crazy release day today!
For those following the Firefox 4 betas we released the fifth one today. Check out the post for details but there is some hot graphics acceleration action on Windows and an audio API that enables awesomeness.
For those not willing to run pre-release software, we released Firefox 3.6.9 today for users on the stable branch. As always there are great crash fixes and security improvements, but we also snuck in a little hardening. Firefox 3.6.9 adds support for the X-FRAME-OPTIONS HTTP header. Check out Michael's blog post about it for details. Big hat tip to Brandon Sterne for working on it and making people more secure. Taking an aggressive hardening approach on stable branches is happening more and more (like enabling the last bits of ASLR in Firefox 3.6.7). I like it!
Because good things generally come in threes, we also released Firefox 3.5.12. Again, more security and stability fixes are always a welcome sight. At this point you should probably be running Firefox 3.6.9 though, as it is way better...trust me!
With this many releases, RelEng and QA had to work overtime. They did amazing work! Thanks to everyone, and thanks especially to Anthony Hughes...he's an update testing machine.
Did I say good things in threes? There was actually even more release shenanigans today. Both Thunderbird and SeaMonkey had releases today as well, though I was less involved and can't speak to all the goodness they bring.
Push notifications for Bugzilla!
I've had some downtime between Firefox releases and chose to work on a pet project on-and-off for the past week. I'm announcing it today as bugzilla-amqp.
What is bugzilla-amqp?
A server-side Bugzilla extension that sends messages to a message broker via AMQP whenever a Bugzilla object (bug, keyword, component, etc) is created or modified.
Why?
It enables push notifications for interesting events in Bugzilla! This is a big deal. Tools no longer have to poll the various APIs when dealing with bug data...instead they can sit back and get notified! Want to know when you are CC'd? Easy! Want to know when a new bug is written? No problem! Take a look at the quick demo video (webm, theora...warning, large!)
Because it talks AMQP, tools interested in the Bugzilla messages/events can be written in just about any language you want for any platform you want.
The impetus for writing this extension came from the desire to integrate Mozilla Pulse (running RabbitMQ) with bugzilla.mozilla.org, having push messages end-to-end.
Sounds awesome! I want this on bugzilla.mozilla.org now!
It won't be rolled out on bmo for a bit yet. All these need to happen:
- There are some features that need to be added first (like, uh, security)
- After that, because there is a fair amount of code (as far as Bugzilla extensions go), it will likely need to go through a security review
- Performance testing needs to happen so that it doesn't bring down bmo inadvertently
- The server running Mozilla Pulse needs to get beefier and the traffic expectations with IT have to be revisited (I promised them it was a prototype after all...)
I have filed bug 589322 to track putting the extension into production on bmo.
Ok, still sounds awesome...where do I get the code?
I've put it at http://github.com/LegNeato/bugzilla-amqp. Let me know if you use it and/or find any issues and feel free to fork away!
Are you some hardcore Bugzilla hacker?
Nope, I'm a Firefox release manager
. The Bugzilla extension system is pretty easy...I highly suggest you take a look if you ever wished Bugzilla did something differently or wanted a feature added.
Reminder: Firefox 3.6.9 and 3.5.12 code freeze is TOMORROW @ 11:59 pm Pacific
Just a reminder that code freeze for Firefox 3.6.9 and 3.5.12 is TOMORROW @ 11:59 pm Pacific time.
If you have any bugs in these queries, we need your attention on them ASAP:
- Firefox 3.6.9 blocking bugs that do not have an approved patch
- Firefox 3.5.12 blocking bugs that do not have an approved patch
If you don't think one of your bugs should be blocking (or you think it won't make code freeze), please say so in the bug or email me directly.
If you have any bugs in these queries, the patch needs to be landed or it will not make the release:
Reminder: Firefox 3.6.6 and 3.5.11 code freeze is TONIGHT @ 11:59 pm Pacific
Just a reminder that code freeze for Firefox 3.6.6 and 3.5.11 is TONIGHT @ 11:59 pm Pacific time.
If you have any bugs in these queries, we need your attention on them ASAP (if you aren't in the critical path for Firefox 4 beta of course):
- Firefox 3.6.6 blocking bugs that do not have an approved patch
- Firefox 3.5.11 blocking bugs that do not have an approved patch
If you don't think one of your bugs should be blocking, please say so in the bug or email me directly.
If you have any bugs in these queries, your patch needs to be landed:
These bugs have the checkin-needed keyword and it would be great for other people to land them:
Ehsan and Reed may beat you to those checkin-needed bugs though!


