Archive for January, 2014

Lack of Maintainership & Finding a Project to Contribute to

Thursday, January 30th, 2014

One of the things I liked about the GNOME Documentation Hackfest (apart from the hospitality of Kat, Dave and the University of East Anglia) was the opportunity of teachers and students popping in and discussing open source project management related aspects with us.

One obvious topic is contributor involvement.
The Number Two question of people interested in contributing to GNOME (right after “How do I get started?”) is “I know programming language XYZ. Which projects would be good?”. Which leads to the question:
What are obstacles for contributors to find projects in language XYZ themselves?

And as volunteer based projects allow project maintainers or translation team leaders to disappear without a warning, new contributors might not realize or know where to escalate in order to become a new maintainer, especially if the single contact point of failure is a private email address of the previous maintainer who will never reply. New contributors do not know how to find out how “maintained” a project is – they would have to find the “log” page of the project on GNOME Git plus understand that translation updates are not a sign of development activity.
How to help contributors avoid writing a patch for an unmaintained dead rotten project where nobody will ever notice and appreciate their contribution?

This problem actually affects a larger group: Translators, documentators and bug reporters all waste time working on projects that will never see a release again. One year ago, one third of the non-archived modules in GNOME Git had not seen any code activity for more than two years. Obviously, these dead projects are not a good idea to contribute to if you have no experience in software project management yet but just want to contribute a small patch that scratches your own itch.

And as we discussed this I pointed to a university paper I wrote a year ago, comparing Apache and GNOME.
Realizing how often I refer to it it’s probably useful to link the PDF file:

Indicators for Missing Maintainership in Collaborative Open Source Projects (PDF)

Very quickly after that discussion, Frédéric created a “GNOME Project Health” webpage based on metrics in that paper.
Frédéric’s page allows to see which listed GNOME maintainers are active, how active the project is (the higher the score, the less activity exists), and in which programming language(s) the project is written. It’s a great start and I owe Frédéric a beer for it.

If you are a GNOME project maintainer you can help improving it:
If your project is mostly written in the programming languages X and Y, add the lines


to the .doap file in the top level folder in Git, and check if the maintainers listed in the DOAP file do not collide with the reality out there.

GNOME Documentation Hackfest, Day 0

Sunday, January 26th, 2014

Reporting live from GNOME Docs Hackfest at Norridge, East Anglia.

Fréd arrived after bypassing some tree falling on his way. But he was very late. Shaun is still in a snowstorm. Ryan has escaped that already. But fearless leader Kat, Dave, Julita, Phil, Michael, and Baptiste made it. Petr plans to arrive in the middle of the night. If his plane does not decide to make even more problems.

Julita plans to refresh the structure of the Evolution user docs to make it more compact plus might take a peek at GNOME Developer Platform Demos.

Phil “arrived on a train, that was pretty good, and I’ve actually resolved a third of the licensing issues of GNOME system monitor.”

Michael and Baptiste visited the Protestant cathedral. Michael worked on system monitor and taking screenshots. Baptiste also kept contact to Fréd so he does not feel too alone and lost. And Sindhu joined remotely.

I went through numerous documentation related bug reports and updated them (plus as a side effect created statistics about all those many unmaintained modules in GNOME Git).
For a short moment I also wondered: Why does GNOME push for using AppData files if we have extensible DOAP files already in each repository? Hmm.

Interested documentation fans in the backyard.

Documentation fans in the backyard of the venue (photo by Michael Hill)

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.

Manually Installing Bugzilla 4.4 on Fedora 20

Saturday, January 18th, 2014

One rainy winter I tried to manually install Bugzilla 4.4 on a Fedora 20 machine by using Bugzilla’s latest stable upstream code instead of the Bugzilla package provided by Fedora. You, being one of my delighted long-term blog readers, already know that one of my favorite hobbies is to run into issues. Generally. Hence allow me to share them with you here, to some extend.

General hint to the reader: RTFM: installation guide. Also ignore /etc/bugzilla/localconfig as it is only used by the Bugzilla package provided by Fedora.

  • cd /usr/share/
  • Download Bugzilla 4.4 via Bazaar (which will get replaced by Git soon): bzr co bzr:// bugzilla44
  • cd /usr/share/bugzilla44/
  • Run to see that I should install numerous packages for functionality. In my case this meant yum install perl-Template-Toolkit perl-Template-GD perl-GDGraph perl-GDGraph3d perl-GDTextUtil perl-MIME-tools perl-HTML-Scrubber perl-TheSchwartz (you can find a nice list of package names on Fedora here).
  • Create a symlink so your Apache web server will find your Bugzilla: ln -s /usr/share/bugzilla44/ /var/www/html/bugzilla44
  • ./ --check-modules – if all packages are sorted out it should now complain about the database.
  • Start the web server and database services: systemctl start httpd.service and systemctl start mysqld.service
  • Database setup
    • Reset the MariaDB/MySQL password in case you forgot: mysqladmin -u root password
    • mysql -u root -p (then enter the password)
    • mysql$> CREATE DATABASE bugs;
    • mysql$> GRANT ALL PRIVILEGES ON bugs.* TO andre@localhost IDENTIFIED BY ‘password123′;
    • Edit /usr/share/bugzilla44/localconfig and insert the previously defined database information:
      db_host = 'localhost';
      db_user = 'bugs';
      db_user = 'andre';
      db_pass = 'password123';
  • Giving /usr/share/bugzilla44/ http://localhost/bugzilla44 a try cannot hurt either to find further problems.


Now let’s finally start running into problems with Apache and SELinux (manuals FTW?).

  • Problem: CGI content displayed as plain raw text in the browser:
    • Remove the preceding # of the line #AddHandler cgi-script .cgi in /etc/httpd/conf/httpd.conf
  • Problem: 403 Forbidden error
    • Check that $webservergroup in /usr/share/bugzilla44/localconfig is set to apache
    • chown -R 751 /usr/share/bugzilla44
    • chown root:apache -R /usr/share/bugzilla44
    • Check /var/log/httpd/error_log and see the line
    • Options ExecCGI is off in this directory: /var/www/html/bugzilla44/index.cgi. So edit /etc/httpd/conf/httpd.conf and add:
      <Directory "/var/www/html/bugzilla44">
      AddHandler cgi-script .cgi
      Options +ExecCGI +FollowSymLinks
      DirectoryIndex index.cgi
      AllowOverride Limit FileInfo Indexes Options
      Order allow,deny
      Allow from all
      Require all granted

      (I run Bugzilla on a test machine and don’t need to care about a secure setup, so my settings might not be good settings for you, obviously.)

  • Problem: 500 Internal Server Error
    • Check /var/log/httpd/error_log and see the line /var/www/html/bugzilla44/.htaccess: Options not allowed here
    • Instead of commenting out lines, double-check that $create_htaccess = 0; is set in /usr/share/bugzilla44/localconfig and delete /usr/share/bugzilla44/.htaccess before it complains about every damn single line in there. Run, as usual.
  • Problem: Try to set up any parameter on the Bugzilla admin page and fail
    • Software error: Error in tempfile() using template data/params.XXXXX: Could not create temp file data/params.abcDE: Permission denied at Bugzilla/ line 270.
    • Wait, obscure and cryptic permission issues even after running chmod a+rwx /usr/share/bugzilla44/data/? That sounds like the main area of expertise of SELinux! But random stuff I found on the interwebs like setsebool -P httpd_enable_homedirs on and setsebool -P httpd_read_user_content on did not help. echo 0 >/selinux/enforce neither (that command likely changed over the last years, see next sentence).
    • Following a blogpost about Nagios vs SELinux, running setenforce 0 to change SELinux’ mode from “enforcing” to “permissive” (you can check via sestatus) finally makes Bugzilla work as expected. Obviously looking at the SELinux context of a specific file via ls -Z and adjusting it via chcon is less pervasive, but I don’t care much about SELinux.

Bugzilla now works for me.

(General hint for people from the future who found this blogpost after searching for how to fix their Bugzilla problem: If you need Bugzilla support, send an email to Bugzilla support instead of using the comment function on somebody’s blog. Cheers.)

2014: Plans.

Monday, January 6th, 2014

Studying bug management

To my disappointment my university seems to have no expertise available to mentor a diploma thesis about best practices and common problems in open source bug management. After ten years of working in this field there are quite some open questions I’d like to see answered and after reading lots of scientific papers and books I yet have to find one covering the many aspects and personas involved, so why not write it?
I plan to do some case study research across FLOSS projects (and I’m thankful to Mr Riehle of the University of Erlangen-Nuernberg who pointed out a good resource explaining how to properly do this).

If you are by any chance a teacher at a German university and could imagine to mentor such a thesis, please feel free to contact me.

Wikimedia Bugzilla

This is worth a separate blog post soon, so for the time being I just point to my task list and status updates for the latest achievements. I also plan to attend FOSDEM which has a dedicated wiki track this year!


There is a documentation hackfest at the end of this month and I hope to work on the Evolution user docs which I maintain, followed by attending FOSDEM in Brussels and DevConf in Brno.


I plan to spend quite some time in Chennai this year by visiting several times. Drop me a line if you live there and would like to discuss Wikimedia, GNOME, or bug management!