Google Summer of Code 2017 — Report

Sebastin Santy
6 min readAug 28, 2017

--

I would like to thank my mentor Dylan Hardison and the whole of Mozilla B-Team for constantly supporting me and reviewing my code during the GSoC project. It was a privilege for me to work with Bugzilla on optimizing the bug filing page.

Hmm, Bugzilla?

Yes, Bugzilla is one of the first products to have evolved in Mozilla (probably just after Firefox). What if I told you that Bugzilla’s development started when I was just a year old (1998). I worked on the forked version of Bugzilla — bugzilla.mozilla.org (bmo). BUT BUT BUT, the good news is that, bmo is to be pushed upstream and will become the main Bugzilla Project. Bugzilla has left a lot of legacy behind — code touched by the greatest of the developers like Gervase and used by NASA (read Curiosity Rover), Apache, RedHat etc.

Bugzilla is a web-based general-purpose bugtracker and testing tool originally developed and used by the Mozilla project.

Project Overview

Github Repository: https://github.com/mozilla-bteam/bmo

My work was to revamp the existing bug filing interface (enter bug.cgi) into a single page interface reducing the multi-hop db access, unnecessary template rendering etc. We decided to go with a greenfield approach, by designing a new interface. Here is how it looks now:

New Bug Interface

I have already documented my weekly progress on my blog (http://blog.sebastinsanty.com/), but I felt I have neither discussed the unique features this interface provides nor the thinking that went behind those decisions.

  • The style was adopted from the Bug Modal design, which was incorporated into show_bug.cgi
  • The structural layout was suggested by Kohei Yoshino, the Mozilla Website (Bedrock) designer. It follows a github-like two column layout which is used in issues and pull requests.
  • The dropdowns use selectize.js for its ease of making AJAX requests easily and its tagging feature resulting in faster development. The components sure look a bit off from the main design, but that is something which I’ll be fixing post-GSoC period.
  • Product specific bug-filing can be done by hitting /new-bug/#<product>. This helps core developers to file bugs faster. Eg. /new-bug/#Firefox will help you file bugs for Firefox. So this means that, these links can also be floated around on the docs of the products for users to file bugs without any hassles.
  • (Backed out, due to some regression) Another feature to ease with faster bug-filing was to not load the component at all, if there exists a general/untriaged component, giving less choices to the user. It has been noticed that, a lot of times bugs are often funnelled into wrong components by users who are not completely aware about the product. This feature will reduce the confusion caused.
  • Files can be attached and reset. Uploading a file means that its description becomes a required field.
  • Some of the panels are collapsed by default. These include ones which aren’t required for the bug to be filed, like attachments/people/ dependencies. This makes the interface cleaner, and gives the users a clear idea of what is required and what is not.
  • (Under Review) The possible suggestions table gives an idea whether there is a similar bug existing. There is also an option to add yourself into the CC List, if you find the desired bug. The table in the existing interface was made using YUI2 which was converted to pure AJAX based calls.

Some of developmental changes that took place when I was working on this:

  • A vagrant update provisioner script which helps in rapid debugging was made. As my project included a lot of client-side work, this helped in scaling down the time required to check each change.
  • Without us working on bmo, would Kohei have thought changing the UX was even possible? Probably not.
  • I reviewed umpteen number of patches :-)
  • We got a lot more confidence on spinning up new REST endpoints, without breaking compatibility with old pages. Ahh, this reminds me of how working on a legacy software is:

Bugs and Pull Requests related to the Project

The following is the list of commits/pull-requests and bugs filed which are related to this project. Bugs describe what each of these commits are intending to do.

(On review) Pull Requests

(Merged) Commits

Backed Out Commit

Pending Work

Almost all work is completed as proposed, except mass testing of the bug interface among the core developers of Firefox and others at Mozilla. People already in the new-bug-testers group are really excited by this fast interface.

Future Work

The future’s awesome. As you might have got a gist that my project triggered a lot of changes within Bugzilla and aroused hope of getting in fresh-blood for the product. BugzillaUX is aiming towards giving a better experience (Watch out for it). We might also give a chance to ReactJS, as Dylan was mentioning how he setup npm on the container. This project strongly influences the opinion that it is the right direction to go.

Conclusion

Completing this GSoC project would also mark my one year anniversary of working with Bugzilla. I am extremely happy with how Bugzilla is moving forward. From the times of using a Bugzilla instance spun-up on a server to using it locally, the work on Bugzilla UX by Kohei and Mary, the work on Phabricator by David Lawrence, David Walsh, Mark Cote, everything is getting exciting by the day. Not to forget the extensive reviews by atoll and the initial help from Emma. We have come a long way.

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -George Bernard Shaw

--

--