2010 was an interesting year for me professionally. Inspired by similar lists online, I present what I did (or can remember at least):

  1. Released Mac OS X 10.6.2 and a bunch of other Apple-related stuff
  2. Left Apple and came to Mozilla in March
  3. Shipped out-of-process plugins in Firefox 3.6.4
  4. Got the idea for Pulse, started a prototype in my spare time
  5. Gave a talk about 3.6.4 and Pulse at the Mozilla summit
  6. Released Firefox 3.0.19
  7. Released Firefox 3.5.9 through 3.5.16
  8. Released Firefox 3.6.3 through 3.6.13
  9. Became a Bugzilla contributor and committer
  10. Released a Bugzilla extension for integration with a message broker (bugzilla-push)
  11. Created a GitHub service hook to integrate GitHub with a message broker like Pulse
  12. Released Firefox 4 beta 6 through beta 8
  13. Obtained commit access to Mozilla’s repositories, though I haven’t pushed anything yet
  14. Moved Pulse out of a prototype and into a Mozilla quarterly goal (which I believe was met)
  15. Took over Jeff’s bztools project
  16. Wrote a MediaWiki extension to integrate wiki.mozilla.org with Pulse (to be released soon)

I’m pretty happy with what I have done so far and am looking forward to doing even more.

New technologies

It was also fun to play around some hot new technologies (and some old but new to me). These are new the ones I became familiar with in 2010:

  • RabbitMQ (and by by proxy a little bit of Erlang)
  • AMQP and STOMP
  • Node.js and Socket.io
  • git and GitHub
  • CouchDB and Riak
  • Mercurial
  • orbited
  • WebSockets

2011 Goals and Plans

2011 is shaping up to be awesome! This is the general plan for the year I am working off at the moment:

  1. I intend for the mechanics of a Firefox release to become 100% automated. This is critical and must happen for 2011. There are too many competent people babysitting scripts and communicating via email and IRC during releases. Luckily, Pulse was brought up in 2010 and will help enable this ;-)
  2. In general I intend to make Pulse a cornerstone of Mozilla’s tools and processes, eliminating polling across the organization and adding information transparency. AMQP / enterprise messaging is the future for Mozilla’s tools. The first higher-level tool I intend to convert once all the current instrumentation is rolled out is TinderBoxPushLog
  3. I will bring up a release management system like I had at Apple. It will become the single source of truth for releases and will be integrated with the build system via Pulse
  4. I want to standardize release and project management processes across all client software that Mozilla ships. This will be critical in 2011 as I am sure there will be many simultaneous releases
  5. I will fix this Bugzilla bug, which should help Mozilla’s Bugzilla workflow immensely
  6. I will fix this Bugzilla bug, which should help anyone who gets bugmail (that’s everyone, right?)
  7. I will fix this Bugzilla bug, so that Ehsan can stop including the functionality in his Firefox extension and I can fix a bug from 1999 (bragging rights, whoo!)
  8. I will release my finished MediaWiki extension that ties MediaWiki to a message broker. It’s done, it just needs to be polished before I can attach my name to it and release it on GitHub
  9. I will publish a video walkthrough detailing how I think Mozilla should structure their repos and approach project and risk management in an accelerated release world
    • Hopefully my proposal will be accepted and implemented. If not, it was an extremely useful mental exercise and will guide some small improvements in the future
  10. I plan to quickly tackle managing the quarterly Firefox releases and will try to make them as smooth as possible
  11. I’ll release my top secret Mozilla-related project I’ve been working on in my “spare time” for the last couple of months. Probably not until the end of the year though
  12. I will take ownership of extension/plugin blacklisting if no one wants it. I’ve been resisting doing so in 2010, but I think it needs an owner and the likely owners are swamped. It can also benefit from some new processes and clear operating guidelines
  13. I really want to blog more about my experiences at Apple, comparing and contrasting with Mozilla. I feel I have a unique position to talk about the release technology and project management sides but haven’t found time in 2010 to do so. Hopefully 2011 will be different and I’ll blog before I forget everything

All three lists have a lot of Pulse/Pulse-related bits in them. This isn’t by chance. Everything I set out to improve at Mozilla needed a system like Pulse and I needed that foundation before I could build higher-level tools and processes. Now that it is in place and people are starting to “get the religion”, I hope I’m going to see a rapid increase in awesomeness. Special thanks to David Dahl and Margaret Leibovic for smiling, nodding, and feigning excitement when I excitedly showed them Pulse messages scrolling by in a terminal every five minutes for the past year. It has to be annoying sitting by me, but they both seemed to take it in stride…or perhaps it was the booze at their desks.

Tagged with:  

4 Responses to Looking back at 2010, forward at 2011

  1. Axel Hecht says:

    There are two ways to phrase this comment, pick one ;-) And yes, it’s my pet comment these days.

    TBPL is a status display, while pulse is about status change.

    Bridge the gap how?

    Or, I don’t believe in pulse doing status for us. It’s great for notifications of all sorts, but it just, AFAICT, can’t answer the question of “how did things go so far?”

    Which to me reads as “we need to commit to a status store”, which pulse is not. Pulse may be a technical detail in how to pass information into that status store, but frankly, I don’t see it as such.

    Just glancing at what TBPL does today, you’re easily dealing with 1k builds at a time. Any secondary datastore will struggle. I’m very much in favor of “fist class data” here.

    Also, TBPL is of course just a different bag of lies, as our builds just don’t do what TBPL expect they do. But that’s a different story than “status vs status change”.

    • Christian says:

      Yes, I do not intend pulse to be a data/status store. For TBPL I was thinking about getting rid of the polling/reloading and scraping it does. The reporting of test and build status could be updated in realtime via Pulse messages once the page has already loaded, or the messages could be used to trigger data refreshes (a pubsub-type thing). Of course, you have to display historical data on first load. That could use the current methods, or transition to a datastore that was populated by Pulse messages…but that’s out of my domain and the scope I was thinking about here

  2. Dan says:

    If you do points 6 and 7 you will be a hero.

    Also, point 13 is missing: “use an automated tool do make some flag changes in Bugzilla, thus wiping random fields in bugs”. You can tick that one off of the list :-)