LegNeato! Christian Legnitto's blog about Mozilla, Apple, technology, and random stuff

23Apr/12Off

Frank Ocean – Swim Good

I like this song but can't stand listening to it because of the horrible grammar. Ugh.

18Apr/12Off

New mediawiki-bugzilla features

I've been looking for high leverage ways to contribute to Mozilla now that my spare time is virtually non-existent. Luckily, mediawiki-bugzilla is gaining a lot of traction at Mozilla and looks to be really helping out. Seeing as I started the project I decided to add some much needed features! These aren't rolled out on wiki.mozilla.org yet but they will be soon (I have a couple of little things to finish first). Code can be found in my github repo (yes, I am currently working to rectify the mozilla/personal dual repo situation).

Status colors

First up, a minor yet helpful addition. When showing bug data in a table, the rows are now colored by their status. Spiffy.

Screenshot of colors

Screenshot of colors

And the code:

<bugzilla>
{
    "whiteboard": "[mediawiki-bugzilla]"
}
</bugzilla>

 

A couple of notes:

  • mediawiki-bugzilla adds CSS classes with the status values on the table automatically
  • The CSS can be changed by the mediawiki administrator by editing the css directly (not ideal) or adding in another css file at [extension location]/web/css/custom.css
  • The "lock" icons and such come from mediawiki. I'm working on removing them (by stopping medawiki from processing the extension's ouput) but if you use a custom theme it shouldn't be an issue
  • For this example, remember that type="table" is the default...that's why it's rendered as a table

Configurable fields/columns

Once people started using the extension the first question was "can I choose which fields to show and hide?" With this change you specify fields in the "include_fields" setting of BZ REST API options as you normally would. Mediawiki-bugzilla will then a) only fetch those fields and b) display those columns.

Custom fields selected and columns shown

Custom fields selected and columns shown

And the code:

<bugzilla>
{
    "whiteboard": "[mediawiki-bugzilla]",
    "include_fields": "id, summary, whiteboard, status, resolution"
}
</bugzilla>

 

A couple of notes:

  • Columns are displayed in the order they are listed in "include_fields"
  • Not specifying "include_fields" gives the default fields
  • Not all fields have custom templates yet. This means some fields (such as assigned_to) won't show up properly. I'm going to be writing a bunch but feel free to submit a patch!
  • Only "include_fields" is supported. mediawiki-bugzilla won't do anything with "exclude_fields"
  • "_default" isn't supported as a field, so list the fields you want explicitly

Javascript tables

Large lists of bugs on a wiki page can get a bit unwieldy. It was requested to be able to sort by columns, search through the results, and paginate to keep vertical space to a minimum. I beefed up the support for client side jquery/Datatable rendering.

Administrators can turn on client-side jquery table support

Administrators can turn on client-side jquery table support

And the code:

<bugzilla>
{
    "whiteboard": "[mediawiki-bugzilla]",
    "include_fields": "id, summary, whiteboard, status, resolution"
}
</bugzilla>

 

A couple of notes:

  • This is currently enabled by the mediawiki admin / all or nothing. Future plans will make it configurable on a per-table basis
  • Pagination is done client-side...it will not make the page load faster
  • Yes, the default skin is ugly. I haven't taken a crack at it yet

Pie chart support

You can currently make bar graphs by setting type="count", display="bar", and including Bugzilla REST API /count parameters. I actually had support for other chart types stubbed out and decided to implement pie charts.

Pie charts of three different sizes

Pie charts of three different sizes

And the code:

<bugzilla type="count" display="pie">
{
    "whiteboard": "[mediawiki-bugzilla]",
    "x_axis_field": "status"
}
</bugzilla>
<bugzilla type="count" display="pie" size="medium">
{
    "whiteboard": "[mediawiki-bugzilla]",
    "x_axis_field": "status"
}
</bugzilla>
<bugzilla type="count" display="pie" size="small">
{
    "whiteboard": "[mediawiki-bugzilla]",
    "x_axis_field": "status"
}
</bugzilla>

 
A couple of notes:

  • You can specify a chart size by using size="small/medium/large". The default size is large. The size attribute doesn't work for bar charts yet
  • I want to embed the numeric data in an accessible format for our screen reader friends. Right now, it is just an image
  • Yes, the default color scheme is ugly. I haven't taken a crack at it yet

Unordered list support

We can make tables, we can make bar charts, and we can make pie charts...why not a simple list? While I was adding support for pie charts I added a simple unordered list display.

Bugs can be displayed in a list

Bugs can be displayed in a list

And the code:

<bugzilla display="list">
    {
        "whiteboard": "[mediawiki-bugzilla]",
        "include_fields": "id, summary, whiteboard, status, resolution"
    }
</bugzilla>

 
A couple of notes:

  • The field/column support I talked about above works here too!
  • Field data is separated by " - ". I haven't taken time to add niceties like "(none)" when there isn't data
  • The odd spacing in the screenshot is caused by mediawiki's default css rules

Better error reporting

It's not perfect, but I've put in a little more support for detecting errors. If the JSON is invalid or your "display" and "type" combination are invalid you will get a message saying so.

Invalid JSON input now shows an error

Invalid JSON input now shows an error

 

And the code:

<bugzilla type="count" display="bar">
    {
        "whiteboard": "[mediawiki-bugzilla]",
        "x_axis_field": "status",
    }
</bugzilla>

 
A couple of notes:

  • PHP doesn't give me the exact JSON parse error so I can't be more helpful. This example has a trailing ',', which isn't allowed in JSON
  • Errors from the Buzilla REST API timing out or PHP using too much memory are not caught / reported
16Mar/12Off

Enjoying the Mozilla memes

I am totally enjoying the Mozilla Memes blog. Hilarious. I just submitted one tonight that I made a while ago. Makes me laugh every time.

Also, when heard about the blog I couldn't help but think of this amazing video that was making the rounds when we started the new release process:

Happy Friday!

5Mar/12Off

Long time no see!

I went a bit underground after leaving Mozilla as an employee. Now that I am situated in my new role, I can talk a little bit more about what I am doing and how it will relate to Mozilla.

I am currently at Facebook and recently graduated bootcamp. I'm on the Release Engineering team with Chuck Rossi working on release related things. Right now I help out with the Facebook.com web releases but I'll be moving into mobile (Android, iOS, mobile web, etc) shortly. It's pretty cool to see how a company the size of Facebook deals with releasing how often they do, the scope of their frontend and backend systems, and the tools and processes they have in place. Once I start working on mobile, I am absolutely giddy I get to work with Mike Shaver again.

So what does this mean for Mozilla? A lot! I've been missing-in-action, waiting for legal approval to work on Mozilla stuff. Now that I have that approval, I should be around more and more. Here's a list off the top of my head of what I intend to work on in my "spare" time:

  1. Making it so source migration is as easy as pushing a button. I started this work before I left but based on the time it took Alex and I to struggle through the last migration it's clear that it isn't nearly good enough. I intend to expand my hacky merge tool to make it solid
  2. I have Bugzilla improvements I have committed to. Some even have patches. I have promised to finish them and I will do so. I know the benefit to Mozillians is great but quite honestly it is hard to motivate myself to work on Bugzilla without feeling the benefit personally. Plus, I have no desire to subject myself to Perl anymore...and that's coming from a guy who works in PHP now (ugh). That being said, I will finish what I started and help the Mozilla community in this way as much as I can
  3. Usable, generic release management tools. Every company I know has tools to track what is/isn't in a branch, overlay interesting events on the repo graph, perform cherry picks / transplant between release branches, etc. I intend to write some reusable components I can use at Facebook as well as Mozilla
  4. Help with mediawiki-bugzilla. I started the project as a proof of concept and it's been great to see Lawrence and Jake Maul get it actually used in production. The project is so useful and so simple I'll probably hack on it in my spare time to let off some steam. Plus, Facebook has a lot of PHP so I guess I'll feel a little bit more at home working on this codebase. Any web developer looking to contribute to Mozilla / open source should take a look at this project...high impact (a lot of open source projects use MediaWiki and Bugzilla), super simple code base, accessible language with no real external dependencies, and very little development red tape (just a pull request on GitHub!)
  5. Channel triage. I actually enjoy triage and I want to take the load off of Alex and others so they can do "real" work during their day. I have some ideas for tools and processes to help out but I plan to triage at least 3 times a week or so...it helps me go to sleep when my mind is racing. First, I need to make sure I have all the proper Bugzilla access but then I will be acting as the Triage Fairy™ as much as possible
  6. Mozilla Pulse. I fumbled the handoff (sorry guys!) but I intend to push Pulse forward as much as I can

I won't be working on Mozilla stuff in any official Facebook capacity, but I'll be around as much as I can in my personal time. I'm excited!

16Jan/12Off

Revolver – Leave me alone

Learned this song on the guitar today, sort of has an old-time feel. Good for a lazy holiday:

13Jan/12Off

Moving on from Mozilla

Today is my last day as a Mozilla employee, though I will always stay a Mozillian. Mozilla is the premier open source project and touching a small part of it has been both inspiring and humbling. Meeting all the smart and talented people I "knew" from reading Planet still blows my mind.

Leaving is very bittersweet for me. We accomplished so much in 2011 and 2012 looks to have even more on tap. Hunkering down and shipping Firefox 4, going through a transition like the new release process, shipping a mobile product, and questioning years of assumptions while figuring it out as we went along was exhilarating. No one (including many Mozillians) thought we could ship Firefox 5 a quarter after Firefox 4. Well guess what, we did. And then we shipped Firefox 6, 7, 8, and 9--all on time. Sure, there were hiccups. Transitions are hard. We laid the foundation for the future and 2012 is the year we take it to the next level.

During my interview, Mike Beltzner (@beltzner) asked me if I identified as a community member. I told him that I lurked around on Planet and Bugzilla, so not really. He looked me in the eye and told me he viewed lurkers as a valuable part of the community, making me feel like a member of the Mozilla family from day one. If you are a lurker, please take note. Of course, now that I know where I can effectively contribute I don't intend to stop...so look for me in bugs and participating in email threads about the correct shade of orange for the Firefox button (kidding!).

I want to publicly thank Johnathan Nightingale (@johnath), Senior Director of Firefox Engineering, for his guidance and advice. He has been both an amazing manager and mentor from day one. His analytical ability, managerial prowess, and technical chops have been inspiring and I hope you get a chance to experience them as I have.

Any release management work / questions should be directed towards Alex Keybl (@alexkeybl). Alex joined us this year from Apple (where he drove features for Mac OS X Lion) and has already made a large impact at Mozilla. I'm sorry that I am leaving but I know Firefox releases will go smoothly in his capable hands.

They say you are supposed to end posts like this with a quote for added effect. I think this quote accurately captures my feelings about moving on from Mozilla:

I'm so excited. I'm so excited. I'm so...scared. - Jessie Spano

Keep up the amazing work and thank you for the past couple of years.

Christian Legnitto - soon to be ex-Firefox Release Manager

4Nov/11Off

Firefox release candidate builds available

In case you missed it, late yesterday we declared a release candidate for the next version of Firefox. Please test it!

Tagged as: , No Comments
31Oct/11Off

New tool to generate CSVs from input.mozilla.org data

Our feedback tool (input.mozilla.org) has great data but I found some of the analysis tools lacking. I wrote a new (ugly) python script to generate CSVs from input data. I then feed the CSVs into a spreadsheet program to visualize:

 

This has already become pretty valuable to me for looking at overall feedback, positive/negative for a particular version or query, etc.

It's a bit rough / hacky, there may be bugs, but you can find it here:

http://hg.mozilla.org/users/clegnitto_mozilla.com/release_tools/file/default/scrape_input.py

The tool requires:

  • Python (v2.6+, which is used on Mac 10.6+)
  • The module "requests". Install it with 'sudo easy_install requests' or 'sudo pip install requests'
  • The module "argparse" (should be in python 2.6+). Install it with 'sudo easy_install argparse' or 'sudo pip install argparse'

The tool currently dumps the CSV to stdout, so you'll most likely want to redirect output to a file.

Input now supports OR queries

When writing the tool I realized I needed to support searching for multiple terms. For example, when trying to get feedback on hangs just searching for "hang" wouldn't give me the complete picture. I needed to search for something more like "hang OR freeze OR responding". I supported this in my tool with queries for each search term and aggregating the results.  I quickly realized there were duplicates in the aggregated counts (input doesn't give me unique ids to de-dupe) so I would only get an upper bound.

I hopped into #input on irc.mozilla.org and asked about OR queries. Dave Dash said it'd probably be easy to support, disappeared for a bit, and then BAM, input supported OR queries (using '|' in the web UI, ',' in my tool)! Thanks Dave!

Pivoting on Firefox version (--version)

Details:

  • Show input types and ratios
  • Allows you to see general "quality"...(praise/issues) is essentially a quality index
  • You can restrict the analysis to a particular search if you want by using '--search'
  • Beta and alpha versions are folded into the main version number

Example usage:

  • python scrape_input.py --version 8.0
  • python scrape_input.py --product mobile --version 8.0
  • python scrape_input.py --version 7.0 --search memory
  • python scrape_input.py --version 6.0 --search hang,freeze,responding

Pivoting on input type (--type)

Details:

  • Track input over the life of a product
  • Breaks down input by version and overall
  • You can restrict the analysis to a particular search if you want by using '--search'
  • Beta and alpha versions are folded into the main version number

Example usage:

  • python scrape_input.py --product mobile --type issues
  • python scrape_input.py --type all
  • python scrape_input.py  --type issues --search hang,responding,freeze

Manually graphing in Numbers

  1. Open the CSV file
  2. Select the first row and make it a header row
  3. Select the date column and other columns to graph
  4. Choose "Share X values" after selecting the data in the gear menu
  5. Click the chart button then scatter chart button
  6. Open the inspector (View > Show Inspector)
  7. Click the chart tab
  8. Click the series subtab
  9. Data symbol -> None
  10. Connect points -> Straight

Have fun!

Tagged as: , , , No Comments
30Oct/11Off

Sufjan Stevens – The Dress Looks Nice On You

This may be hipster, but it's amazing:

24Oct/11Off

A modest Bugzilla keyword format proposal

I just sent an email to dev-planning proposing a new keyword format. Nothing earth-shattering, but I think the upside is huge. I'll reproduce it here, but feel free to comment in the dev-planning thread.

Proposal

{code type="python"}
#(namespace)/..../(leafnode keyword)
{/code}

That's it, pretty simple. Examples:
{code type="python"}
#relman/triage/needs-info
#relman/triage/defer-to-group

#ux/papercuts/user-control
#ux/papercuts/useful-error-messages

#crashkill/watching
#crashkill/blocklist-candidate
#crashkill/3rd-party/adobe
#crashkill/3rd-party/adobe/contacted

#gfx/bugkill/too-old
#gfx/bugkill/bitrot
{/code}
...etc

Why?

  • "#" denotes a keyword that doesn't widely apply across the project
    1. Humans and tools can skip over easily
    2. Trivial bugzilla patch to make it sort at the bottom / last (I'll attach it to the bug in a bit). We can even filter them out of the autocomplete entirely if desired
    3. Trivial to make a watchdog script that enforces states and makes sure only certain people are adding / removing certain groups of keywords (which can be eventually expanded to a bz extension)
    4. Easy to let anyone with editbugs create them with a bugzilla patch (if desired)
  • "#" denotes a keyword in this system
    1. Tools can rely on the format and process it, unlike current keywords (is '-' part of the keyword or a namespace/separator? Depends!)
  • Hierarchical structure of tags
    1. Tools can query for keywords lists at the proper depth easily
    2. Humans can easily group keywords at a glance
    3. Humans can query easily through the existing bugzilla interface (e.g "show me everything Release Management is triaging")
  • Keyword subsections can use whatever rules they like, only "#" in the 1st position and "/" anywhere is special (spaces obviously don't work)
  • (ab)using the current keyword system. This is essentially a small step to moving keywords into a tree model, rooted via component. I need something NOW and can't wait for bugzilla improvements (and already have enough of them assigned to me).

Why not use the whiteboard?

The whiteboard is junk! I can't do historical queries for when a whiteboard substring was removed. The bugmail isn't explicitly clear and I have to take time to scan the string, fun regex stuff in scripts, etc.

If bugzilla had a decent keyword or tag system the whiteboard would go away...it's a kludge.

Future plans?

  • Make anyone able to grab a "#" namespace and then create as many keywords as they want inside without having the current heavy-weight keyword access. This should actually be easy to do in bugzilla
  • Release Management may migrate this sort of stuff to our web system outside Bugzilla, but for now we're (ab)using current tools
  • We need to replace Bugzilla's keyword system. Yesterday.

Please let me know what you think and if you or your group would find such a change useful. The goal would be for it to be invisible to anyone who isn't using it and wildly useful to those who do.