Archive for the ‘computer’ Category

GNOME Bugzilla: Your Bugs and your Product Overview.

Monday, February 23rd, 2015

GNOME Logo
Bugzilla logo by Dave Shea

  • The UNCONFIRMED bug status (which can be disabled per product) will be removed as it is mostly not used and confuses reporters. Tickets with UNCONFIRMED status will be merged into NEW status as announced on desktop-devel-list and at the top of every GNOME Bugzilla page.
    If you are a GNOME project maintainer and want to keep the UNCONFIRMED status for your GNOME Bugzilla product you can opt out until the end of February.
  • I encourage you to give the product pages and your user page a try!
    They have become more useful:
    Browse Product

    Browse Product

    • Target Milestones (if existing), Priorities (if actually used and not just kept as the “normal” default) and Severities are now listed first, to get a quick overview for those projects who might use Bugzilla to do some project planning (so far I have not seen that much though). Static information like components or versions now comes after.
    • Versions now sorts by newest versions first. You should be more interested in bugs reported in recent versions.
    • The previously shown needless NEEDINFO queries by date were moved to the side bar and merged into one query. The query results are sorted by last change.
    • In the side bar, “Bugs without a response” is a link again (though it is not exactly what it says, it’s rather a query for reports with only a single comment, hence also a mismatch between the displayed number and the search result number when you click it)
    • Moved “New Patches” into its own new “Patches” section under “New and unreviewed”. All patch related information for a project is now in a single place. Click it and review a patch!
    • The “GNOME-love bugs” query shows reports that have been recently changed first – more likely that recently changed ones are not outdated and something new contributors could work on.
    • The “activity” link next to “Git repository” could give contributors a quick idea how maintained the project is (only works if the project is hosted in GNOME Git).
    Describe User

    Describe User

    • Your patches are now listed right after “What bugs are assigned to me” and “On which bugs do I need to provide input” and above the long list of “Open issues” that you once upon a time filed. Patches now also display the summary of the corresponding bug report. (Still have to remove the useless patch ID.)
  • With above changes I’d like to make the “Browse Product” and “Describe User” pages give answers to “What is important?” and “What should I work on / review?”. I’d appreciate feedback if that’s considered helpful. For bugzilla.gnome.org itself this works pretty well, as you can see on its product page.
  • Not yet available: I want the frontpage to look like this (thanks to jimmac for the custom icons; ignore the wrong color of the top bar):
    Potential future frontpage

    Potential future frontpage


    This was already live for a few minutes but I reverted this change as the server started cycling through cached older versions (no idea what happened), plus I have the feeling that the skin handling is still problematic (my fearless guinea pig Shaun still had Bugzilla’s “Dust” skin enabled in his user settings so things looked pretty broken). Need to make sure that everybody uses the GNOME skin before doing further custom skin changes.
  • 18 months ago I blogged a series of Bugzilla related posts. Though this focused on Wikimedia Bugzilla, there might be some helpful information or tweaks you are not aware of:

Wikimedia’s migration to Phabricator: FOSDEM talk.

Thursday, February 19th, 2015

Earlier this month, Quim Gil and I gave a talk at FOSDEM:

Wikimedia adopts Phabricator, deprecates seven infrastructure tools:
First hand experiences from a big free software project on a complex migration

The talk description and the presentation slides are available. At some point there will likely also be a video (probably under 2015 and H1308).

The talk tried to cover three aspects: The decision driving process in a large distributed project, the technical and planning aspects of such a complex migration that nobody has tried before, and describing some of the functionality of the new tool (Phabricator) itself.

On product design.

Friday, February 13th, 2015

…and while I was playing with GNOME’s new Bugzilla instance trying to get rid of some upstream feature bloat, I looked at upstream’s Bugzilla front page and spend the next hours wondering where to add eight more Search buttons/links/forms so it’ll become a full dozen.

Upstream Bugzilla front page with four search options

Upstream Bugzilla front page with four search options

I mean, seriously?

GNOME Bugzilla upgraded to 4.4.

Tuesday, February 10th, 2015

Bugzilla logo by Dave Shea

Dear GNOME community, you all owe Krzesimir Nowak, Andrea Veri, and Olav Vitters some icecream and drinks: The Bugzilla software running on bugzilla.gnome.org has been upgraded to the latest stable version available.

So much for the general information that I am aware of.

And some smaller stuff that I was into

I was confused that some people saw me as a point of contact for the Bugzilla upgrade, as I did nothing apart from testing, some smaller tweaks, and providing grumpy input and feedback. Though I admit that lately I have performed some smaller taxonomy changes unrelated to the actual migration though:

…and some smaller testing and simple tweaks in Bugzilla itself on its way to 4.4:

  • Common links on the frontpage: “Reported by and assigned to me”, “Created in last 5 days”, “Changed in last 5 days”. Maybe more to come, let’s see (the frontpage still has too much unhelpful stuff).
  • The Patch Report shows the author and size of patches now (bug 675822). Maybe you are more motivated to review a patch if it’s a small chunk and if it’s an unknown contributor, or one that you trust?
  • The list of your patches on your user page now displays the summary of the bug report.
  • Improved and added some stock answers for triagers.
  • Gerrit IDs in comments now automatically link to the commit (thanks to a hacking session with Olav; bug 559537). Requirement: Your Git repository name needs to match your Bugzilla product name.

Vague personal future ideas for GNOME Bugzilla

  • Best development practices:
    As I don’t see someone driving a discussion process to move GNOME to different (better?) infrastructure tools soon, I would like to make the custom “Browse product” and “Describe user” pages more useful for users to get an overview what’s there to work on and what is relevant (high priorities, new patches, target milestones) in a project. Many projects don’t really use Target Milestones or Priorities so far though I’m convinced it can be helpful if the tool properly supports you.
    Regarding practices, I’d also discourage setting a default human assignee instead of a virtual assignee for components so the list of assigned bugs per user is actually what you yourself really plan to work on.
    Furthermore, you probably do not want to set a default target milestone for the next version. It is just unrealistic and does not allow you to plan properly.
    All such stuff, you know.
  • Maintainers can be encouraged to disable old versions and target milestones: Dropdown lists become shorter. (Though not too short because users might still want to report issues in older versions. You do not help reporters if you disable the version they use – they might still report their bug but just not set the Version correctly.)
  • Remove the “URL”, “Tags”, “Hardware” fields in bug reports. Feature creep.
  • Another area that welcomes improvement is avoiding cookie-licking. Your user page lists the tasks which are assigned to you. Do you realistically plan (means: rough timeframe and actionable steps identified, and not just some “would be good” feeling) to work on those tickets assigned to you? Also, your patches are listed there.
    Bugzilla also offers an overview list of open tasks per assignee (might load slowly) to see the full situation.
  • A cronjob to dump taxomony changes into an email sent to Bugzilla maintainers as I am interested in consistency.
  • Split the “docs” components of products into “User documentation” and “Developer documentation” components so it is easier for doc contributors to find tasks to work on. To discuss on d-d-l.
  • Disable the “reviewed” patch status. It means nothing. Either a patch needs more work, or it is ready to go. To discuss on d-d-l.
  • As the section heading says: Those are just ideas. They require discussion and time but you are very welcome to steal these ideas from me.

But what ever the future brings (or not):
You all owe Krzesimir Nowak, Andrea Veri, and Olav Vitters some icecream and drinks.

Wikimedia in Google Code-in 2014

Wednesday, February 4th, 2015
Google Code-in 2014

Google Code-in 2014

Google Code-in is an annual contest for 13 and 17 year old students. They get introduced to contributions which make free and open source software (FOSS) development happen.
For the second time in December 2014 and January 2015, Wikimedia was proud to be one of the 12 mentoring organizations which provided tasks that students could choose to work on. Students who complete tasks receive a certificate and t-shirt from Google.

In those seven weeks, 48 students successfully completed 226 Wikimedia tasks, supported by 30 mentors from the community. Tasks are not only about dealing with code but also about documentation, research and testing. The variety of achievements is huge:

Task statistics per week

Task statistics per week

It’s been satisfying (and a little addictive too) to see your changes merged into a project used by millions, as Unicodesnowman, one of the participating students, writes.

Check out how you can contribute to Wikimedia and the list of easy software bugs to start with.

Thank you and congratulations to all the students who became part of Wikimedia and joined and supported its mission to freely share knowledge. You have done awesome work! Special congratulations to Wikimedia’s two Grand Prize Winners Danny Wu and Mateusz Maćkowski and to our finalists Evan McIntire, Geoffrey Mon and Pranav Kumar!

Thank you to all our mentors and their commitment, coming up with task ideas and spending time on weekends to work together with students and quickly review their contributions.

And last but not least, thank you to Google for organizing and running this contest, creating awareness of and interest in Free and Open Software projects. The full list of winners and finalist across organizations has been published.

GNOME Bugzilla and You.

Sunday, January 25th, 2015

GNOME Logo

GNOME’s Bugzilla instance is old. Too old.

It will get upgraded in the next weeks.

You should help by playing with the test instance. Go read these instructions and do it!

Let me make one thing clear already: Dear GNOME community, you all owe Krzesimir, Olav and Andrea some icecream and drinks.

More information to come. Stay tuned.

Good bye Bugzilla, welcome Phabricator.

Wednesday, December 17th, 2014

<tl;dr>: Wikimedia migrated its bug tracking from Bugzilla to Phabricator in late November 2014.

After ten years of using Bugzilla with 73681 tickets and ~20000 user accounts and after months of planning, writing migration code, testing, gathering feedback, discussing, writing more code, writing documentation, communicating, et cetera, Wikimedia switched from Bugzilla to Phabricator as its issue tracking tool.
Phabricator is a fun adventure game collaboration platform and a forge that consists of several well-integrated applications. Maniphest is the name of the application for handling bug reports and tasks.
My announcement from May 2014 explained the idea (better collaboration and having less tools) and the decision making process that led to choosing Phabricator and starting to work on making it happen.

Wikimedia Phabricator frontpage an hour after opening it for the public again after the migration from Bugzilla.

Wikimedia Phabricator frontpage an hour after opening it for the public again after the migration from Bugzilla.

Quim already published an excellent summary of Wikimedia Phabricator right after the migration from Bugzilla, covering its main features and custom functionality that we implemented for our needs. Read that if you want to get an overview of how Phabricator helps Wikimedia with collaborating and planning in software development.
This blog post instead covers more details of the actual steps taken in the last months and the migration from Bugzilla itself. If you want even more verbose steps and information on the progress, check the status updates that I published every other week with links to the specific tickets and/or commits.

Preparation

After reviewing our project management tools and closing the RfC the team started to implement a Wikimedia SUL authentication provider (via OAuth) so no separate account is needed, work on an implementation to restrict access to certain tasks (access restrictions are on a task level and not on a project level), and creating an initial Phabricator module in Puppet.
We started to discuss how to convert information in Bugzilla (keywords, products and components, target milestones, versions, custom fields, …), which information to entirely drop (e.g. the severity field, the history of field value changes, votes, …), and which information to only drop as text in the initial description instead of a dedicated field. More information about data migrated is available in a table. This constantly influenced the scope of the script for the actual data migration from Bugzilla (more information on code).

We already had a (now defunct) Phabricator test instance in Wikimedia Labs under fab.wmflabs.org which we now started to also use for planning the actual migration.
There’s a 7 minute video summary from June describing the general problem with our tools that we were trying to solve and the plan at that time. We also started to write help documentation.

As we got closer to launching the final production instance on phabricator.wikimedia.org, we decided to split our planning into three separate projects to have a better overview: Day 1 of a Phabricator Production instance in use, Bugzilla migration, and RT migration.

On September 15th, phabricator.wikimedia.org launched with relevant content imported from the fab.wmflabs.org test instance which we had used for dogfooding. In the case of Wikimedia, this required setting up SNI and making it work with nginx and the certificate to allow using SUL and LDAP for login. After the production instance had launched we also had another Hangout video session to teach the very basics of Phabricator.

To provide a short impression of further stuff happening in the background: Elasticsearch was set up as Phabricator’s search backend, some legal aspects (footer, determining the license of submitted content) were brought up, phab-01.wmflabs.org was set up as a new playground, and we made several further customizations when it comes to user-visible strings and information on user pages within Phabricator. In the larger environment of Wikimedia infrastructure interacting with the issue tracker, areas like IRC bots, interwiki links, on-wiki templates, and automatic notifications in tasks about related patches in the code review system were dealed with or being worked on.

Paying attention to details: The “tracked” template on Wikimedia sites supports linking to tasks in Phabricator, while still redirecting links to Bugzilla tickets via URL redirects (see below).

We also had a chicken and egg problem to solve: Accounts versus tickets. Accounts in Bugzilla are defined by email addresses while accounts in Phabricator are user names. For weeks we were asking Bugzilla users and community users to already create an account in Phabricator and “claim” their Bugzilla accounts by entering the email address that they used in Bugzilla in their Phabricator account settings. The plan was to import the tickets and account ‘placeholders’ and then use cron jobs to connect the placeholder accounts with the actual users and to ‘claim’/connect their past Bugzilla contributions and activity by updating the imported data in Phabricator.

On October 23th, we made a separate “bugzillapreview” test instance available on Wikimedia Labs with thousands of Bugzilla tickets imported. For two weeks, the community was invited to check how Bugzilla tickets are going to look in Phabricator after the migration and to identify more potential issues. The input was helpful and valuable: We received 45 reports and fixed 25 of them (9 were duplicates, 2 invalid, and 9 got declined).

A task imported from Bugzilla in the Phabricator preview instance.

A task imported from Bugzilla in the Phabricator preview instance.

Having had reached a good overview, we created a consolidated list of known issues and potential regressions created by the migration from Bugzilla to Phabricator and defined a final date for the migration: November 21-23.

Keeping timestamps of comments intact (such as the original creation date of a ticket in Bugzilla or when a certain comment was made) was still something to sort out at this point (and got tackled). It would have been confusing and would have broken searches that triagers need when trying to clean up (e.g. tickets which have not seen updates for two years).

It was also tricky performance-wise to keep the linear numbering order of reports which was requested by many people to not solely depend on URL redirects from bugzilla.wikimedia.org to phabricator.wikimedia.org which we planned to set up (more information on the redirect setup). As we already had ~1400 tickets in Phabricator we went for the simple rule “report ID in Bugzilla + 2000 = task ID in Phabricator”.

Regarding documentation and communication, we created initial project creation guidelines, sent one email to those 66 users of personal tags in Bugzilla warning that tags will not be migrated, sent two emails to the 850 most recently active Bugzilla users asking them to log into Phabricator and provide their email address used in Bugzilla to claim their imported contributions as part of the migration already (for comparison, the average number of active users per month in Bugzilla was around 500+ for the last months), put migration announcement banners on mediawiki.org and every page on our Bugzilla, sent reminders to the wikitech-l, mediawiki-l, wikitech-ambassadors, and wmfall mailing lists.

After a last ‘Go versus No-Go’ meeting on November 12th, we set up the timeline with the list of steps to perform for the migration, ordered, with assignees defined for each task. This was mostly based on the remaining open dependencies of our planning task. We had two more IRC office hours on November 18 and 19 to answer questions regarding the migration and Phabricator itself.

While migrating, the team used a special X-Forwarded-For header to still be able to access Bugzilla and Phabricator via their browsers while normal users trying to access Phabricator or Bugzilla were redirected to a wikipage telling them what’s going on and where to escalate urgent issues (MediaWiki support desk or IRC) while no issue tracker is available. With aforementioned URL redirects in place we intended to move and keep Bugzilla available for a while under the new address old-bugzilla.wikimedia.org.

Migration

The page on mediawiki.org that users were redirected to while the migration was taking place.

The page on mediawiki.org that users were redirected to while the migration was taking place.

The migration started by switching Bugzilla to read-only for good. Users can still log into Bugzilla (now available at old-bugzilla.wikimedia.org) and e.g. run their searched queries or access their list of votes on the outdated data but they cannot create or change any existing tickets.

We pulled phabricator.wikimedia.org and disabled its email interface, switched off the code review notification bot for Bugzilla, and switched off the scripts to sync Bugzilla tickets with Mingle and Trello.

The data migration started by applying a hack to workaround a Bugzilla XML-RPC API issue (see below), running the migration fetch script (tasks and comments), reverting the hack, running the migration create script (attachments), moving Bugzilla to old-bugzilla.wikimedia.org, starting the cron jobs to start assigning Bugzilla activity to Phabricator users by replacing the generic “bzimport” user by the actual corresponding users, and setting up redirects from bugzilla.wikimedia.org URLs.

A task before and after users have claimed their previous Bugzilla accounts (positions of comments in the right image manually altered for better comparison).

A task before and after users have claimed their previous Bugzilla accounts (positions of comments in the right image manually altered for better comparison).

After several of those data migration steps we performed numerous tests. In parallel we prepared emails and announcements to send out and publish once we’re finished, updated links to Bugzilla by Phabricator on dozens of wikipages, updating MediaWiki templates on the Wikimedia, and further small tasks.

Paying attention to details: The "infobox" template on MediaWiki extension homepages linking to the extension's bug reports at the bottom, now handled in Phabricator instead of Bugzilla.

Paying attention to details: The infobox template on MediaWiki extension homepages linking to the extension’s bug reports at the bottom, now handled in Phabricator instead of Bugzilla.

For those being curious about time spans: Fetching the 73681 Bugzilla tickets took ~5 hours, importing them ~25 hours, and claiming the imported user contributions of the single most active Bugzilla user took ~15 minutes.

But obviously we were pioneers that could not rely on Stackoverflow.
Even if you try to test everything, unexpected things happen while you are running the migration. I’m proud to say that we (well, rather Chase, Daniel, Mukunda and Sean when it came to dealing with code) managed to fix all of them. And while you try to plan everything, for such a complex move that nobody has tried before, there are things that you simply forget or have not thought about:

  • We had to work around an unresolved upstream XML-RPC API bug in Bugzilla by applying a custom hack when exporting comments in a first step and removing the hack when exporting attachments (with binary data) in a second step. Though we did, it took us a while to realize that Bugzilla attachments imported into Phabricator were scrambled as the hack got still applied for unknown reasons (some caching?). Rebooting the Bugzilla server fixed the problem but we had to start from scratch with importing attachments.
  • Though we had planned to move Bugzilla from bugzilla.wikimedia.org to old-bugzilla.wikimedia.org after exporting all data, we hadn’t realized that we would need a certificate for that new subdomain. For a short time we had an ugly “This website might be insecure” browser warning when users tried to access the old Bugzilla until old Bugzilla was moved behind the Varnish/nginx layer with its wildcard *.wikimedia.org certificate.
  • Two Bugzilla statuses did not get converted into Phabricator tags. The code once worked when testing but broke again later at some point without anybody realizing but this was noticed and fixed.
  • Bugzilla comments marked as private got public again once the cron jobs claiming contributions of that commenter were run. Again this was noticed and fixed.
  • We ended up with a huge feed queue and search indexing queue. We killed the feed daemon at some point. Realizing that it would have taken Phabricator’s daemons ~10 days to handle the queue, Chase and Mukunda debugged the problem together with upstream’s Evan and found a way to improve the SQL performance drastically.
  • We hadn’t thought about switching off some Bugzilla related cronjobs (minor) and I hadn’t switched off mail notifications from Bugzilla so some users still received "whining" emails until we stopped that.
  • We had a race condition in the migration code which did not always set the assignee of a Bugzilla ticket also as the assignee of the corresponding task in Phabricator. We realized early enough by comparing the numbers of assigned tickets for specific users and fixed the problem.
  • I hadn’t tested that aliases of Bugzilla reports actually get migrated. As this only affected ~120 tickets we decided to not try to fix this retroactively.
Phabricator daemons being (too) busy handling the tasks mass-imported from Bugzilla.

Phabricator daemons being (too) busy handling the tasks mass-imported from Bugzilla.

We silently reopened Phabricator on late Sunday evening (UTC) and announced its availability on Monday morning (UTC) to the wikitech-l community and via the aforementioned blogpost.

A list of dependency tasks handled before completing the migration from Bugzilla to Phabricator is available.

Advantages

Phabricator has many advantages compared to Bugzilla: Wikimedia users do not reveal their email addresses and users do not have another separate login and password. (These were the most popular complaints about Bugzilla.)

Integration with MediaWiki's Single User Login via OAuth - no separate login.

Integration with MediaWiki’s Single User Login via OAuth – no separate login.

There is a preview when writing comments.
The initial description can be edited and updated like a summary while the discussion on a task evolves.
Users have a profile showing their latest activity.
There’s a global activity feed.
There is a notification panel on top.
The UI looks modern and works pretty well on devices with small screens.
Tasks can have either zero or one assignee. In Bugzilla an assignee must be set even if nobody plans to work on a ticket.
Tasks can have between zero and unlimited projects (such as code bases, sprints, releases, cross-project tags) associated. In Bugzilla, tickets must have exactly one product, exactly one component, exactly one target milestone, and between zero and unlimited cross-project keywords. That also solves Bugzilla’s problem of dealing with branches, e.g. setting several target milestones.
Projects have workboards (a card wall) with columns for planning sprints (Bugzilla only allowed getting lists of items which you cannot directly interact with from the list view.). Thanks to Wikimedia Deutschland we now also have burndown charts for sprint projects.

The workboard of the Wikimedia Phabricator project, right after the Bugzilla migration.

Burndown chart for a two week sprint of the Wikimedia Analytics team.

Burndown chart for a two week sprint of the Wikimedia Analytics team.

Disadvantages

From a bugmaster point of view there are also small disadvantages:
Some searches are not possible anymore via the web interface, e.g. searching for open tasks which have the same assignee set for more than 12 months ("cookie-licking") or tasks that have been closed within the last month.
Phabricator is more atomic when it comes to actions: I receive more mail notifications and it also takes me slightly longer to perform several steps in a single ticket (though my local Greasemonkey script saves me a little bit of time).

Furthermore, admins don’t have the same powers as in Bugzilla. The UI feels very clean though (breadcrumbs!):

Administrator view for settings policies in Maniphest.

Administrator view for settings policies in Phabricator.

New territories

Apart from the previous list of unexpected situations while migrating, there were also further issues we experienced before or after the migration.
Mass-importing huge amounts of data from an external system into Phabricator was new territory. For example, Phabricator initially had no API to create new projects or to import tickets from other systems. No Phabricator instance with >70000 tasks had existed before – before the migration we had a crash affecting anonymous users and after the migration the reports/statistics functionality became inaccessible (timing out). Those Phabricator issues were quickly fixed by upstream.
And of course in hindsight, there are always a few more things that you would have approached differently.

Next steps

All in all and so far, things work surprisingly well.
We are still consolidating good practices and guidelines for project management (we had a Hangout video session on December 11th about that), I’ve shared some queries helpful for triagers, and we keep improving our Phabricator and bug management related help and documentation. The workflow offered by Phabricator also creates interesting new questions to discuss. Just one example: When a task has several code related projects assigned that belong to different teams, who decides on the priority level of the task?

Next on the list is to replace RT (mostly used by the Operations team) and helping teams to migrate from Trello and Mingle (Language Engineering, Multimedia and parts of Analytics have already succeeded). In 2015 we plan to migrate code repository browsing from gitblit and code review from Gerrit.

OMG we made it

A huge huge thanks to my team: Chase (Operations), Mukunda (Platform), Quim (Engineering Community Team), the many people who contributed code or helped out (Christopher, Daniel, Sean, Valhallasw, Yuvi, and more that I’ve likely forgotten), and the even more people who provided input and opinions (developers, product managers, release management, triagers, bug reporters, …) leading to decisions.
I can only repeat that the upstream Phabricator team (especially Evan) have been extremely responsive and helpful by providing feedback incredibly fast, fixing many of our requests and being available when we ran into problems we could not easily solve ourselves.

Cheers!

Wikimedia in Google Code-in 2014: The first week

Wednesday, December 10th, 2014

Wikimedia takes part in Google Code-in (GCI) 2014. The contest has been running for one week and students have already resolved 35 Wikimedia tasks. You can help making that more (see below).

Google Code-in 2014

Some of the achievements:

  • Citoid offers export in BibTeX format (and more contributions)
  • Analytics’ Dashiki has a mobile-friendlier view
  • Echo‘s badge label text has better readability; Echo uses the standard gear icon for preferences
  • Wikidata’s Wikibase API modules use i18n for help/docs
  • Two MediaWiki extensions received patches to not use deprecated i18n functions anymore
  • MediaWiki displays an error when trying to create a self-redirect
  • The sidebar group separator in MediaWiki’s Installer looks like in Vector
  • The Wikimedia Phabricator docs have video screencasts and an updated Bug report life cycle diagram
  • Huggle‘s on-wiki docs were updated; exceptions received cleanup
  • Pywikibot‘s replicate_wiki supports global args; optparse was replaced by argparse
  • Reasons for MediaWiki sites listed as defunct on WikiApiary were researched
  • Wikimedia received logo proposals for the European Wikimedia Hackathon 2015
  • …and many more.

Sounds good? Want to help? Then please spend five minutes to go through the tasks on your to-do list and identify simple ones to help more young people contribute! Got an idea for a task? Become a mentor!

Wikimedia in Google Code-in 2014

Monday, December 1st, 2014

At work I spent the last weeks mostly working on preparing Wikimedia’s move from Bugzilla to Phabricator which successfully happened last weekend after ~7 months of planning (worth another blog post) and preparing Wikimedia’s participation in Google Code-in (GCI) 2014 (specific steps are listed in the corresponding task in Phabricator). Eventually, Wikimedia got accepted by Google as one of the twelve Free and Open Source organizations taking part in GCI.

Google Code-in 2014

GCI is a contest for 13-17 year old students and starts on December 1st. Students are offered tasks that should take an experienced contributor (knowing the toolchain and infrastructure) up to four hours. Tasks can be about code, documentation, QA, training, outreach, user interface and research. Wikimedia has a central planning and information wikipage.

Last year Wikimedia ended up with 273 tasks, 46 students, and approximately 30 mentors in GCI. The results were above our expectations (as I was initially sceptical if Wikimedia had enough resources). Based on the common questions that students had we improved our onboarding documentation for new contributors (not only GCI students) and our instructions for GCI mentors. Hence Wikimedia is better prepared than last year: So far we have approximately 200 tasks available (not all of them will be available to students immediately) and 24 mentors. Still we need way more tasks and mentors for the next six weeks!

Become a mentor!

If you are active in the Wikimedia community, have that small task on your To-Do list that you haven’t managed to work on yet, and can imagine mentoring a student: Check out our mentor’s corner, register, and create your task!

Locally installing Phabricator on Fedora 20

Monday, November 10th, 2014

Phabricator project logo

Uhm, no blog post for ages. Work and university kept me way busier (and less energetic to do much other things) than expected.

As announced in May 2014, Wikimedia will replace Bugzilla with Phabricator very soon for issue tracking. The Wikimedia Phabricator production instance is up and running and the migration from Bugzilla and RT is the next step on our migration timeline. A comparison between Bugzilla and Phabricator and documentation are available.

Time to publish my quick notes about installing Phabricator locally on a Fedora 20 machine. Maybe it’s useful for somebody, maybe not.

Phabricator’s official installation guide is pretty wonderful so I’ll only cover what I, being a simple user avoiding to think on his own and just blindly following guidelines, still had to do (which might be very obvious to tech-savvy users). I expect you to know that systemctl restart httpd.service, systemctl restart mysql.service and more /var/log/httpd/error_log are your friends.

  • First of all, I got the raw content of a php file displayed in my browser. Obviously I had to install the php package first. Heh.
  • Phabricator complained about the undefined function mysql_real_escape_string – the package php-mysqlnd was not installed.
  • The next and last problem not covered by documentation was Request parameter ‘__path__’ is set, but empty. Your rewrite rules are not configured correctly. The ‘__path__’ should always begin with a ‘/’. This required changing the corresponding RewriteRule in /etc/httpd/conf/httpd.conf to have a slash in front of $1.
  • Going to http://localhost.foo in your browser should now allow you to set up your admin account.
  • To get greeted with less “unresolved setup issues”: sudo yum install php-mbstring php-gd php-pecl-apcu.

In the end, my httpd.conf file looked like this:

<VirtualHost *>
  ServerName localhost.foo
  DocumentRoot /var/www/html/phab/phabricator/webroot
<Directory "/var/www/html/phab/phabricator/webroot">
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>
  RewriteEngine on
  RewriteRule ^/rsrc/(.*)    -                       [L,QSA]
  RewriteRule ^/favicon.ico  -                       [L,QSA] 
  RewriteRule ^/(.*)$       /index.php?__path__=/$1  [B,L,QSA]
  ErrorLog /var/log/httpd/error_log
</VirtualHost>