Announcing mediawiki-bugzilla, a MediaWiki extension to embed bug data
Do you use wiki pages to track things? Tired of copy and pasting bugzilla queries and bug information? Me too. I got fed up one day and decided to do something about it and the result is mediawiki-bugzilla.
What is mediawiki-bugzilla?
It is a server-side MediaWiki extension that provides read-only access to the Bugzilla REST API. It's basically a working proof of concept at this point but I will be beefing it up in the coming weeks.
Why did I write my own MediaWiki extension?
I deal with wiki pages, bugs, and triage daily. It seemed stupid to be copying data and sometimes I wanted to embed up-to-date bug information in various wiki pages. I looked for solutions and found the excellent Bugzilla Reports extension. Unfortunately, it didn't fit my needs:
- Bugzilla Reports needs direct access to the Bugzilla database. Yikes! Not only would I not get that access that would mean we would have to security audit the whole thing. Also, it was unclear that the assorted groups and permissions could be preserved across queries
- The specification/query language was homegrown. In addition to wiki markup one had to take time to learn how to tune and use a specification unique to Bugzilla Reports
- I'm not the best PHP programmer in the world but the code seemed overly complex and was difficult to dive into
I actually hacked together a proof-of-concept backend to have Bugzilla Reports query the Bugzilla REST API instead of the database but it didn't work quite right and wasn't maintainable.
I wanted to make an extension that is painless to use, easy to develop, and has no possible way of exposing restricted bugs. I didn't want to create my own query specification / format, so I piggybacked off Gerv's excellent Bugzilla REST API. The extension is basically an easy way to make REST API calls from MediaWiki so the docs can be used for the extension as well.
How to use mediawiki-bugzilla
You essentially use this extension in this way:
<bugzilla> (JSON REST API query key/value pairs) </bugzilla>
For example, the following would be used to get all P1 bugs in the Bugzilla product:
<bugzilla> { "product": "Bugzilla", "priority":"P1" } </bugzilla>
Notice that this is the same example used in the Bugzilla REST API documentation. Any query you can do via the API you should be able to embed in a wiki page using this extension.
I also stubbed out support for charting using the Google Charts API:
<bugzilla type="count" display="bar"> { "product": "Bugzilla", "priority": "P1", "x_axis_field": "severity" } </bugzilla>
If you put both of the above examples into a wiki page you get something like this:
I know the tables aren't styled yet. I'm going to be using jquery UI + the datatable plugin, with a pref to fall back to standard HTML tables without javascript.
All this info (and more!) can be found in the README.
Next steps
The major thing I am going to add is caching of the queries every 5 minutes or so while allowing manual cache overriding. This should make it so 50 people loading a wiki page with 10 queries at the same time doesn't overwhelm Bugzilla.
After that I will beef up the charting and add some docs. Then we'll get this rolled out on wiki.mozilla.org!
As always, patches welcome. The code is very simple and it should be very easy to add new features as there aren't really any right now.
Why are there no Firefox 5.0.1 and 3.6.19 automatic updates for Windows and Linux?
This newsgroup discussion inspired me to talk about Firefox 5.0.1 and 3.6.19, the situation / trade-offs encountered, and our ultimate decision process.
First, some background. We test pre-release versions of Apple's latest OS, Mac OS X Lion (10.7). Our users also test on their own and we see their crash reports in our crash reporting system. Apple seems to have introduced a bug in their ATS framework in a previous Lion seed. The bug makes Firefox (all versions) extremely unstable. We reported it to Apple but there are only so many bugs that can be fixed and unfortunately this one didn't make the cut for their GM seed. Because Apple had announced "July" as the release of Lion we knew we couldn't just wait for Firefox 6's release (August 16th) to fix it. At the same time, it came to our attention that the latest Java update released by Apple on Mac OS X Snow Leopard (10.6) broke Java for Firefox 5 users. Clearly we had to create out-of-band updates to address both issues.
Immediately, we questioned what platforms we should ship the updates to. It seemed odd to release an updated Firefox to all users on all platforms when the bugs only affect the Mac population.
There are some distinct downsides to releasing across all platforms in this situation:
- We know update fatigue is very real...last we checked over 7% of users don't update specifically because they are annoyed about too many update offers (see Gerv's post as well). To subject Windows and Linux users to the heavyweight update process, potentially annoying them enough to not update to Firefox 6 in August is a big concern
- The updates aren't trivially small. Profile-guided optimization on Windows makes it so the binaries aren't exactly the same for a rebuild. Additionally, the code fixes aren't conditionally compiled so the resulting binaries would be even more different. Though binary patch / delta updates reduce the impact, we still don't feel comfortable having our entire Windows and Linux populations download data that did nothing for them
- More QA / qualification is required and there is more opportunity for issues to crop up (such as automation failures, packaging errors, etc)
Of course, there are some downsides to releasing only for Mac users in this situation:
- User confusion. Windows and Linux users may see the update announcements and think their version is insecure / there is something wrong with automatic updates
- Supporting tools may expect all platforms to have the same supported version
- Our update automation only supports patching to the last update. When we go to release Firefox 6 and Firefox 3.6.20 all non-Mac users will get the full update rather than a binary patch update (unless we try to do manual hackery)
- The Mozilla.com website only supports specifying a "latest version". It is not broken down by platform. We have to offer all platforms for download on Mozilla.com or only offer the older version, exposing new Mac users to the two fixed problems until they update (which may not happen if they keep crashing in the middle of the download)
- Due to the way our update server works, we have to pop up a window offering Firefox 5 to the freshly updated Firefox 3.6.19 Mac users or make it so "Check for updates" on 3.6.19 doesn't offer Firefox 5--both options not ideal
This is why release management is hard. Rarely is there a good option and often it takes too long to get the proper data needed to make an informed decision. Just gathering the above information from various stakeholders took a fair amount of time. To make matters more frantic, we needed to get the updates out as soon as possible to release before Lion's ship date (which is still unknown but thought to be soon).
I looped in product management, as they are the ultimate product "owners" and know how to reason about the assorted tradeoffs and their impact on both our users and Firefox in general. After conferring with product management we decided the downsides of releasing for all platforms outweighed the ones for releasing just for Mac.
We verified with supporting system owners that releasing only for Mac would not cause issues (crossing off #2 above), chose to offer all platforms on the website (largely mitigating #4), and made a call to turn off manual update offers to Firefox 5 for 3.6.19 users (#5 above). We also have time to figure out how to manually hack around patch packages to mitigate #3 but made it clear we are willing to live with the current situation when Firefox 6 / Firefox 3.6.20 comes along.
This decision and process could definitely have been messaged more clearly. We were moving quickly and I was at a team offsite that stole more attention than anticipated. I'm happy with the decision we took but realize there was no "correct" decision in this situation. Both ways had tradeoffs and if we chose releasing to all platforms I imagine I would be writing a similar post explaining why.
Danger Mouse & Daniele Luppi (featuring Jack White) – Two Against One
Playing this awesome song on the guitar these days:
A small Bugzilla improvement
With the recent Bugzilla 4.0 rollout on bugzilla.mozilla.org comes a small but useful usability improvement. It's so small you may not have noticed (I wrote it but didn't notice for weeks!), so I decided to blog about it. The bug I filed and fixed was:
- Bug 585802 - Change the cc/user autocomplete (and backend) usermatching to ignore spaces / search on space separated names
Previously, searching for "Christian L" returned all users with "Christian" in the first or last name as well as all users with "L" in the first or last name. As you can imagine, this was a long list to search through (lots of names have an "L" somewhere) and made searching by name useless--especially when you didn't know how to spell someone's name.
Most people work around this bug by searching just for a IRC nick using ":[ircnick]". IRC nicks are generally unique which produces a smaller list, and inserting the colon assures that there are little to no substring matches.
The search behavior really annoyed me so I dug in, patched Bugzilla, and changed the behavior:
Notice the only people shown match "Christian L" rather than everyone with an "L" in their first or last name
I now find myself searching for irc nicks less and less and just using a person's name. This is one less mental step for me as I no longer have to map from a person to an irc nick in my head.
This was my first Bugzilla patch and the first improvement I wrote that got rolled out on bugzilla.mozilla.org. Special thanks to Max for guiding me through the patch / Bugzilla codebase.
I hope that this small change made Bugzilla a little more usable for everyone.
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!
I’m racing amateur supermoto at Infineon this weekend!
I'm racing amateur supermoto at Infineon this weekend. It's part of the West Coast Moto Jam, a big event that includes all types of motorcycle racing (motocross, dirt track, superbike, etc).
I'll be racing 3 classes:
- Saturday: Asphalt-only Open beginner
- Sunday: Open Novice/C and Open beginner
There is a 30% chance of rain on Sunday and I am not sure what I am going to do as I don't have rain slicks. I'm not sure I really want to cut my tires as they are pretty new and honestly I am not hardcore enough to really want to race in the rain.
I'm really excited about the races in general! I took Thursday off work to practice on the track and I loved it. The dirt section is a little gnarly though (there are pictures at http://mikedoran.zenfolio.com/p533645150). I'm planning on taking it slow and not trying to go fast through it though.
I also probably have some spare tickets if anyone knows me in real life and is interested (they are free and include starting grid passes!)
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.
Come join the new Firefox release team at Mozilla!
Here at Mozilla we release a fair amount of software, most recently Firefox 4:
Photo by Bob Moss
With the new Firefox rapid release process managing the details of those releases is even more critical as we absolutely cannot slip the schedule. Because the schedules are set in stone we need to manage a lot more up front. Additionally, with releases shipping on a faster cadence there is less time for mistakes to be caught. When one adds in new platforms (smartphones, tablets), new products (Firefox Mobile, Firefox Home), and new channels (Nightly, Aurora) there is clearly a growing need for project and release management.
To meet this growing need Mozilla is hiring for a new release management team!
Is this you?
We currently have two positions available:
Associate Engineering Project Manager - Releases: We're looking for someone at the beginning of their career who can learn the ropes and grow to be an experienced member of the release management team. Problem solving, great communication skills, and technical chops are a must!
Engineering Project Manager - Releases: We're looking for someone with tons of experience managing software releases, hopefully at internet scale. This person will hit the ground running, taking the lead on many releases as well as driving process improvements.
What is Release Management?
Wikipedia has a somewhat decent description of what release management actually is. The main takeaway is the fact that it is a project management function, not development (writing the code for the bits that are eventually shipped), QA (testing the bits that are eventually shipped), or Release Engineering (managing the systems that build, package, and deliver the bits). All these groups have differing priorities and worldviews yet need to interact on the same project--that's where release management comes in.
Don't worry, release management is not just playing with schedules, sending emails, and organizing meetings. There is ample opportunity to create tools (examples aren't hard to find) , help define the direction of the product (by driving features or hashing out new processes), and make decisions that directly impact hundreds of millions of people worldwide.
Darn, I don't live in the San Francisco Bay Area
While our preference would be to have the employees work out of our Mountain View, CA office, it is not explicitly required. You don't have to live in the San Francisco Bay Area, California, or even the United States! We have offices all over and for the right candidate / timezone we might even consider 100% remote (though your effectiveness will likely be diminished as a large part of the job is interaction with other people).
If you do want to move to the San Francisco Bay Area, we can investigate how to get you here.
Sweet, sign me up!
Great! We want to fill these positions quickly, so get your resume in order and apply via the jobs website:
Ellie Goulding – Lights (Bassnectar Remix)
Heard this song in a video that was on Reddit. Love it. Totally going to use this as the soundtrack to some of my motorcycle race videos (assuming I can remember to bring my camera to the track this time).