Archive for the ‘wikimedia’ Category

Wikimedia to migrate its Product Management Tools to Phabricator

Monday, May 19th, 2014

Slightly more correct title might be “Wikimedia to migrate its software development product/project code review issue tracking management planning tools to Phabricator”. Or something like that.

The problem

The Wikimedia technical community has used plenty of different tools for tracking bugs / product management / project management / todo lists. Bugzilla, RT, Gerrit, Mingle, Trello, Scrumbugs, Google Docs, to mention most of them.
From my personal point of view, Wikimedia Foundation is pretty bottom-up: Each team can experiment and use those tools they prefer and suit them. That also means teams might have moved from Bugzilla to Trello to Mingle to Google Docs while other teams prefer(ed) other tools. Bugzilla is our public issue tracker but misses a lot of functionality when it comes to agile development workflows, design review work, or activity feeds.

We also have some connectivity between these tools. Bingle/Bugello to sync some parts between Bugzilla and Mingle/Trello, or its-bugzilla (previously “bugzilla-hooks”) to have Gerrit post comments in Bugzilla tickets about related patches (if the bug number was correctly refered in the commit message). But things are brittle – for example, just this Friday the Gerrit→Bugzilla notifications broke.
All in all, the multitude of tools and channels is not helpful for cross-team collaboration, keeping track of what’s happening, and transparency of discussions and decisions in general as things are discussed in several places.

The idea

In late 2013, the idea was to start a discussion about a possible agreement on a recommendation for a smaller set of tools that teams could agree upon. My colleague Guillaume and I had the pleasure to facilitate the discussion and to ensure it doesn’t remain an idea only. References were a previous evaluation attempt in 2009/2010 and the Gerrit evaluation in 2012.

The steps

The first step was asking interested teams and individuals to describe their needs and workflows on a wiki discussion page.
Its content was then consolidated by Guillaume and cleaned up a little bit more by me. (I felt reminded of GNOME’s decision process to migrate from Subversion to Git but that was a survey among GNOME foundation members and hence a very different approach.)

After having those (sometimes contractive) needs and workflows collected, we tried to decrease the items in the list of candidate tools to consider, plus investigate and encourage discussing them on the related discussion page. For candidate tools not having an online test instance offered on the project’s homepage we wondered whether to set up test instances on Wikimedia Labs to make testing easier, but we left it to anybody strongly favoring a tool to set up that tool. Wikimedia Deutschland already had Scrumbugs instance in production (Scrum on top of Bugzilla) we could point to, and for Phabricator somebody had set up a test instance in Wikimedia Labs already.

To gather the broader community opinion and broader support for investigating more potential (wo)manpower, we started to prepare a Request for comments (RFC). While we listed several options at the beginning (Keep the status quo; status quo+Fulcrum; status quo+Scrumbugs; move completely to Phabricator; move partially to Phabricator; move to GitLab) the feedback quickly turned this into one question to ask the community: Move to Phabricator?
We ran this RFC for three weeks until May 6th and announced it widely on mailing lists and via banners on top of Bugzilla and mediawiki.org.

Parallel to running the RFC, we were working on sorting out the blockers for a potential migration from Bugzilla and documenting things. My colleague Quim created a comparison page between Phabricator and Bugzilla.

The decision

Phabricator project logo

The result of the RFC is that there seems to be general support for moving from our infrastructure tools to Phabricator. This won’t all happen at the same time though – we will start investigating replacing Bugzilla, RT, Trello, Mingle.
For the code review functionality (currently done via Gerrit), more work in Phabricator is needed to fit the needs defined by our community, for example when it comes to Continuous Integration. We do not plan to switch off Gerrit on the day we start using Phabricator in production and we got more items to sort out (see the list of code review related items).

For managing the project to move to Phabricator we use the Phabricator test instance itself (dogfooding for the win), by tracking missing features compared to our existing tools, and tasks that need to be solved for the migration. Also, we asked users of existing tools what they would specifically miss in Phabricator by creating (sub)tasks in our Phabricator test instance.

We have not created a Phabricator production instance yet to which we would potentially migrate to, because in the past Wikimedia ended up with a lot of tools by not enforcing migration.

Spreading the word and resource allocation

For the last months we also ran IRC office hours every two or three weeks in order to discuss and answer questions related to the project.

Last weekend the Wikimedia Hackathon took place in Zürich. There were several Phabricator related sessions (videos available for the sake of transparency; the first two videos are more like discussions though):

  1. A general quick introduction to Phabricator by my colleague Shahyar
  2. A discussion among ~10 people of what needs to be sorted out and done for Day 1 of Phabricator in production (being tracked in this Phabricator project board), plus related stakeholders and who’s going to work on what.
  3. A session by Shahyar specifically explaining the code review concept and tool in Phabricator (remember: we do not plan to switch from Gerrit to Phabricator for code review on the first day)

Current status and next steps

  • General and central information page about Wikimedia’s Phabricator instance.
  • Planning board for Wikimedia Phabricator Day 1 in Production (You see several columns here: ‘Need discussion’ needs more thoughts first until we know how to solve those tasks; ‘Ready to Go’ are tasks for which the way forward is clearly defined and somebody could start working on them; ‘Waiting for upstream’ are tickets that we have reported to upstream; ‘Doing’ is what is currently actively being worked on.)
  • The team working on Wikimedia Phabricator and the stakeholders are defined. We have tasks such as investigating migrating Bugzilla and RT data to Phabricator, plus implementing missing functionality like restricting access to certain projects by default (like for Bugzilla’s “Security” product or RT’s procurement queue) via namespaces. The WMF Technical Operations team will set up low-level infrastructure and puppetize our Phabricator instance. We have stakeholders defined to keep in contact with the team of Product Managers and the Platform and Release Engineering/QA team, we have more interested stakeholders which will provide input to help making decisions and driving things forward, and I am happy to also see volunteers being interested to get involved by diving into the code.
  • To track the tasks that Wikimedia is interested in in Phabricator’s upstream task tracker, we have a “Wikimedia” project in upstream Phabricator and the corresponding planning board.

The usual disclaimer: Plans might be subject to change and there is intentionally no timeline yet.

How you can help

Check out the Get involved section on the central project page and the planning board for Wikimedia Phabricator Day 1 in Production if there are tasks that interest you!

Thanks

I would like to thank everybody in the community who has provided input, help and support. Upstream Phabricator developers have been extremely responsive and interested in discussing our needs and fixing issues – it’s a great pleasure to work with them.
Furthermore, getting to this point would have been impossible without my wonderful colleagues in the Wikimedia Engineering Community Team who have helped so much with communication, prioritization, planning, support.

Wikimedia’s Road to Bugzilla 4.4

Thursday, March 6th, 2014

(How we puppetized, upgraded and moved Bugzilla to another server)

Though we currently also evaluate Wikimedia’s project management tools, we will have to stick with our current infrastructure for a while. Among many other tasks, I spent the last months preparing the upgrade of Wikimedia’s Bugzilla instance from 4.2 to 4.4. Some reasons for upgrading can be found in this Bugzilla comment.

In late November 2013 I started by cleaning up Wikimedia Bugzilla’s custom CSS which was copied about five years ago and not kept in sync. It turned out that 16 of 22 files could be removed as there was no sufficient difference to upstream’s default CSS code (Bugzilla falls back to loading the default CSS file from /skins/default if no custom CSS file is found in /skins/custom). Less noise and less diffing required for future upgrades. In theory.

After testing these CSS changes on a Wikimedia Labs instance and merging them into our 4.2 production instance, I created numerous patches and put them into Gerrit (Wikimedia’s code review tool) by diffing upstream 4.2 code, upstream 4.4 code, and our custom code.

At the same time, Wikimedia’s Technical Operations team wanted to move the Bugzilla server from the kaulen server in our old Tampa datacenter to the zirconium server in our new Ashburn (Eqiad) datacenter. While you’d normally prefer to do only one thing at a time, Daniel Zahn (of Technical Operations) and I decided to create a fresh Bugzilla 4.4 instance from scratch on the new server to see into which problems we would run. During this process Daniel Zahn turned the old setup on kaulen, which was largely manual and had organically grown over the years, into a proper Puppet module. For every “missing module” error we ran into we avoided installing anything from Perl’s CPAN in Bugzilla’s /lib folder and ensured we just rely on distribution packages, for a much cleaner install. Daniel Zahn installed the needed packages by adding them to puppet code. While doing this we also removed Bugzilla’s Sitemap extension as it created sporadic Search::Sitemap errors when running Bugzilla’s checksetup.pl (plus it’s unmaintained anyway). Furthermore I ran into another runtime error to fix.

After fixing all checksetup.pl issues and having Bugzilla accessible via a web browser, only Bugzilla’s upstream CSS was displayed instead of our custom CSS. Neither was Wikimedia’s custom CSS offered as an option in the browser, nor could I log into the new Bugzilla (to check which theme is set as default in the admin settings) as the database dump we used for testing predated the creation of my user account.

After Sean Pringle of Technical Operations deployed a more recent Bugzilla database dump I expected further problems due to upstream changes to CSS loading. I was happy to see that I had been wrong: No problems with our custom CSS theming anymore. Instead, I ran into problems with our custom “See Also” field changes: Adding and removing such URLs triggered errors, and URLs themselves were not displayed (but their corresponding “Remove” checkbox). Thanks to upstream help in #bugzilla on Mozilla IRC I finally found out that Perl’s use base instead of use parent was the culprit.

After creating symlinks to /extensions/WeeklyReport/ to avoid 404 errors for the “Weekly Bug Summary” link in the sidebar (our setup is slightly busted) and after fixing two problems with our cronjobs for whining and data collection we agreed on a date to copy the database, do some maintenance work, and switch the DNS entry. This was announced one week in advance by adding a banner to Bugzilla via its announcehtml parameter.

A few hours before the switch on February 12th 2014, Daniel lowered the Time-to-live (TTL) values of the DNS entry of our Bugzilla. When the migration started, I set Bugzilla’s shutdown parameter to make the web UI inaccessible and also the WebService API return a 503 error for the Bingle script that syncs Bugzilla with Wikimedia’s Mingle instance. This was important to make sure that nobody can write anymore to the old database. We updated the IRC channel topic in #wikimedia-tech to tell that Bugzilla is under scheduled maintenance and logged the action in #wikimedia-operations so it got added to Wikimedia’s Server admin log. All in all we had only forgotten two minor things: Our Gerrit integration (a bot adding Gerrit notifications about related patches as comments in Bugzilla) bot was not able to write and got a 503 error back – Chad quickly disabled it. And our Nimsoft watchmouse sent an “ALERT! Bugzilla: Service Temporarily Unavailable” message to the Operations mailing list.

Sean Pringle migrated the old database from db9 in Tampa, to a new database on db1001 in Eqiad. After this was done, Daniel Zahn ran checksetup.pl to apply the scheme upgrades needed for 4.4.

After 30 minutes of testing to make sure everything works as expected we deployed two more custom patches: Showing common queries on the frontpage and making saved reports work. While having the downtime I also switched off bugmail to do some mass-changes without spamming everybody: I merged some version numbers in the “MediaWiki” product to have a shorter Version dropdown, removed the wikibugs-l watcher account from some bug reports as it is unneeded (set as a global watcher in Bugzilla anyway, hence a potential issue if a ticket was moved to a restricted product like “Security” still triggering public bugmail).

A few minutes before the end of the announced downtime of three hours, Daniel switched DNS so the new Bugzilla on the new server became available to the public. A few hours later, to work around isses for clients not supporting SNI, Daniel changed the order in which Apache loads virtual hosts. This ensures that older clients like Internet Explorer on Microsoft Windows XP will always get to see Bugzilla instead of other miscellaneous web services sharing the same hardware. I had also overlooked a small UI issue that I fixed two days later.

Now that all is done, the result can now be seen on bugzilla.wikimedia.org. All steps to upgrade Wikimedia Bugzilla from 4.2 to 4.4 were documented on a wiki page. You can find all of our custom modifications here.

Wikimedia in Google Code-In 2013

Wednesday, January 22nd, 2014

Google Code-In 2013 Logo

Google Code-In (GCI) 2013 is over and the winners have been announced! Congratulations to everybody!

Quim Gil and I organized the participation of Wikimedia in GCI this year. We set up a central wikipage that we pointed students to for recurring general questions. Mostly these were about expectations on communication, how to use IRC, how to set up a development environment and the toolchain (Git, Gerrit, Bugzilla), plus a list of our mentors and their IRC nicknames and timezones (some enthusiastic students welcome being reminded of timezones, plus having patience is one of the good lessons to learn).
We also had a section for mentors explaining how to write good GCI tasks and which sentences and information should be part of every task description.

For the Wikimedia Engineering Community Team, GCI was a helpful lesson to prepare improving our Annoying little bugs landing page for new contributors (still on my TODO list). Students hopefully found interest in contributing to a great FOSS community (I have seen numerous students who continue contributing and are still active after the contest has finished). I hope that Wikimedia will be able to invite the most active students to the Wikimania conference.

We ended up with way more tasks available than expected (and more than 200 successfully finished), had a number of students who really impressed us by code quality (number of patch reviews required) and speed, and Quim managed surprisingly well to convince established developers to become mentors. Also, the nine hours of time difference between Quim and me was a big advantage in order to respond quickly to requests.

All together, GCI was successful and participating in GCI was good decision, contrary to my initial reluctance.
I would like to thank Google and all involved mentors and students for their hard work and for making this possible.

Bugzilla Tips (XI): Reports: Tickets closed last week by resolution

Friday, August 30th, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

This episode goes deeper into Creating reports and tables and Bugzilla’s Advanced Search.

Three weeks ago a development team asked how to get the number of Bugzilla tickets closed in the last seven days by some resolutions (e.g. FIXED, WONTFIX, INVALID, WORKSFORME) while not being interested in the number of tickets closed as DUPLICATE or LATER.

Another usecase for tabular reports in Bugzilla: The vertical axis will display the components which the team maintains and the horizontal axis will display the bug report resolutions:

bugzilla-closedstats1

We manually selected the components of the team in the “Components” list (keep the Control key pressed to make a multi-selection), and selected all resolutions which should be listed in the bug report (see here for the meaning of the “—” resolution). Keep in mind that these resolutions only refer to the current status of the bug reports.

bugzilla-closedstats2

As we only want to know the number of tickets who were resolved in the last week, we need to query for changes of the resolution. This is where the Custom Search comes into play which allows logical combinations of conditions. For our example:

bugzilla-closedstats3

The generated report looks like this:

bugzilla-closedstats4

Though we chose to include INVALID and WONTFIX resolutions in the search criteria above, the table does not have INVALID and WONTFIX columns because no tickets were closed with that resolution in the last week. Similarly there is no row for the “CLDR” component chosen in the search criteria above because no CLDR ticket was resolved in the last week.

Above example explains how to exclude statuses from the table which you are not interested in. If you want all resolutions displayed in the table anyway (and as setting a resolution requires changing the bug status to RESOLVED), you might already guess that there is an easier way by using “Search By Change History”:

bugzilla-closedstats5

Now in case you wonder why setting the resolutions via the custom search is not sufficient and why it is also required to set the current resolution in the “Product / Component / Status / Resolution” lists above as search criteria: It avoids including tickets which already got reopened in the meantime.

If the numbers are slightly different than your expectations, note that until Bugzilla version 4.2, -7d refers to the beginning of the day in the timezone that Bugzilla is set to, not to the last 168 hours. This has changed in Bugzilla 4.4 though, -1d refers to the last -24h while -1ds refers to the start of the day.

Bugzilla Tips (X): Triage helper tools: Greasemonkey scripts

Friday, August 23rd, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

If you read a lot of Bugzilla tickets per day you run into some recurring situations. For example, a bug report might miss sufficient information and you want to point its reporter to a wikipage which explains how to write good bug reports, or you clean up older rotting tickets without enough information and while closing them you want to explain to the reporter why you close the report.

In such situations, having some one-click stock answers (or “canned responses” as others call them) can come in handy in order to save time. I’ve been using several Greasemonkey scripts in my Firefox browser over those years. The two Javascript files which I use in Wikimedia Bugzilla are available to everybody in the code repository. They can be checked out by running the command git clone https://gerrit.wikimedia.org/r/p/wikimedia/bugzilla/triagescripts.git
To use them in Firefox, one has to install Greasemonkey, visit the Git web interface of the repository with Firefox and click the “Raw” links. An installation dialog will open. Note that these scripts only work if you have canconfirm and editbugs permissions in Bugzilla.

This is how it looks after installing the scripts:

bugzilla-triagehelpers-stockanswers

In the picture above, I clicked the “[Close:WorksForMe]” answer. An explanatory command (which also automatically picks up the name of the reporter) is added and the status “RESOLVED WORKSFORME” is set.

As time goes by I’ve added more functionality for my convenience, mostly links to places which are related to functionality exposed in the Bugzilla interface:

bugzilla-triagehelpers

Most useful to me is

  • coloring reporters based on their email addresses (I might spend less attention on a report created by an established developer or employee than a newcomer),
  • coloring the component (MediaWiki has hundreds of extensions, and extensions which are deployed on Wikimedia servers might receive more attention than a non-deployed 3rd party extension),
  • a link to search for other reports created by the same user, and
  • a link to a graph of the priority distribution of tickets for the component (to check how realistically priorities are set – if you only have open tickets with high priority for your component, then something is wrong).

While the code of these Greasemonkey scripts would welcome some cleanup and refactoring, it works for me. Plus today I finally introduced a bunch of boolean variables at the top of the scripts so users can easily define which functionality s/he wants to enable (or not). You are welcome to give it a try (and provide patches if you feel like hacking away).

Of course all this functionality could also be added to the Bugzilla code on the server but I do not want to clutter the Bugzilla user interface even more for everybody by default.
Note that there is also a “proper” upstream Bugzilla extension called Canned Comments available since May 2012 which I have not played with yet.

Bugzilla Tips (IX): Excluding less important reports from search results

Friday, August 16th, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

Sometimes I’d like to exclude certain bug reports from the search results in Bugzilla.
The most common case is excluding enhancement requests (in order to only get “real” bugs) and excluding lowest and unprioritized priorities (the available values for priorities and severity may differ in other Bugzilla instances), to only have more important stuff listed in the results.

Go to Bugzilla’s Advanced Search and select the product/component that you are interested in, as always. In the “Detailed Bug Information” section, select all values which you do not want to exclude from the Severity and Priority fields:

Selecting Priority and Severity values

Bugzilla Tips (VIII):Using flags to track branches and versions

Friday, August 2nd, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

This episode covers an aspect of release management: Branches.
Bugzilla’s support for tracking bugs and bug fixes in several branches/versions has been notoriously bad.

I have seen two ways how software projects using Bugzilla handle this: One way is to clone bug reports and use the Version and Target Milestone fields strictly. Hence one bug report only affects one branch (version), and the very same bug is handled in a separate bug report for a different branch/version.

Another way is to use flags. Flags can have four states:

  • ?: Somebody requested a decision.
  • -: The request was refused.
  • +: The request was approved.
  • By default the field is empty, and no decision is required / the bug report is not affected.

Flags in Wikimedia Bugzilla:

Tracking-branches-flags-wm

Still, using flags requires agreements on workflows, for example after setting “+” (approved) the bug report should only be closed as RESOLVED FIXED once the fix has actually been merged into the branch.

Since version 4.4, bugmail includes an “X-Bugzilla-Flags” email header which allows filtering mail on it. Furthermore, in contrast to keywords, flags can be configured to automatically notify certain email addresses whenever such a flag request is set.

Mozilla Bugzilla even has a more complicated custom implementation of this which covers both testing whether a version is affected and whether a version has received a bug fix, allowing more than the four states mentioned above:

Tracking-branches-flags-moz

If you use a different approach to track branches in Bugzilla, let me know in the comments!

Bugzilla Tips (VII): Simpler searching for open tickets only

Friday, July 26th, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

If you go to Bugzilla’s advanced search and would like to see only those tickets in your search results which are still open, I have seen users selecting all non-closed statuses (like “UNCONFIRMED”, “NEW”, “ASSIGNED”, “REOPENED” etc. – the exact statuses depend on the configuration of your Bugzilla) either with several mouse clicks while holding down the Ctrl key, or by using arrow keys and Shift on the keyboard.
But you can have the same results with one click in the “Resolution” field: Choose “– – –”.

This is how it looks in Wikimedia Bugzilla:

Screenshot from Wikimedia Bugzilla

Only when a bug report gets resolved (e.g. by fixing it, or marking it as a duplicate) it receives a resolution like FIXED or DUPLICATE. Before it does not have any resolution (hence the “– – –”). This resolution is kept for the follow-up VERIFIED status, but if the report gets reopened it is removed again.

And this is how it looks in upstream Bugzilla:

Screenshot from upstream Bugzilla

Bugzilla Tips (VI): Creating reports and tables

Friday, July 19th, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

Quite often I want to quickly check how things are going for specific projects, teams and individuals. Bugzilla’s reporting functionality provides some basic functionality for that. Go to Reports (a link in the sidebar on Wikimedia Bugzilla, and in the footer at the bottom of other standard Bugzillas):

bugzilla-tips-reports1

Click on Tabular Reports:

bugzilla-tips-reports2

You will get the usual advanced query interface, with additional settings at the top:

bugzilla-tips-reports3

One common usecase for me are tables displaying the severity × priority numbers for bug reports of a specific product or component. For this, I set the “Vertical Axis” field to “Priority” and the “Horizontal Axis” field to “Severity”, and in the interface below I choose one Product (in this example: “Datasets”) and set the Resolution field to “—” as I am only interested in unresolved reports. After clicking the “Generate Report” button I get this table:

bugzilla-tips-reports5

Of course you can also select several products by setting “Multiple Tables” to “Product”.

Another usecase is to check which individuals are set as assignees for how many bug reports whenever I wonder if things scale. For this I set “Vertical Axis” to “Assignee”, leave “Horizontal Axis” blank, leave “Product” blank (so the results are global) and set “Resolution” again to “—” (as I am only interested in unresolved, open reports):

bugzilla-tips-reports-assignees

Click on the table headers to sort the columns.

Or if you have Voting enabled in your Bugzilla, you can get a list how many reports have which number of votes by following the steps above by setting “Vertical Axis” to “Votes” instead of “Assignee”.

Note: Saved reports, similar to saved searches, are available from Bugzilla 4.4 on.

Bugzilla Tips (V): Saved and shared searches

Friday, July 12th, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

If you find yourself running the same (or very similar) searches in Bugzilla from time to time, you might want Bugzilla to remember your search at the bottom of the list of search results:

bugzilla-tips-columns-saved

Enter a descriptive name in the text field behind “Remember search as” and click the “Remember search” button:

bugzilla-tips-saved-searches2

Bugzilla will confirm the successful creation:

bugzilla-tips-saved-searches3

Your search will now be available as a link in the sidebar of Wikimedia Bugzilla, or in footer at the bottom of other (standard) Bugzillas:

bugzilla-tips-saved-searches5

If your query could also be useful for other Bugzilla users (e.g. members of your development team), you can share your saved search. Go to your preferences (a link in the sidebar on Wikimedia Bugzilla, and in the footer at the bottom of other standard Bugzillas):

bugzilla-tips-user-watching1

Click “Saved Searches”:

bugzilla-tips-saved-searches4

Here you can share your search by enabling the “Share With a Group” checkbox, or also display saved searches that other users have shared:

bugzilla-tips-saved-searches4