A long overdue post!

I delivered a talk on Graph based health analytics for GNOME Games in GUADEC 2016 in Karlsruhe, Germany on August 13.

Sadly it was a remote talk from Dublin because I couldn’t make it in person to Germany because the German embassy in Dublin refused to grant me an emergency visa and the waiting time for an appointment was over 5 weeks : /

I hope to work on more interesting stuff and come back to present it and meet my friends at GNOME in the next summit.

Here is the recorded talk:

and a few photographs:

Thanks to the GNOME foundation for offering me travel and accommodation sponsorship  to attend the summit and a special thanks to the local team for setting up such an amazing event!


GNOME.Asia summit 2016

My first ever GNOME summit!

It was such a fulfilling experience to meet contributors from all over the world, and finding out numerous ways to contribute to the GNOME project apart from what I’ve always been doing for the GNOME games!

Me in the middle with Andre Klapper and David King

I delivered two talks in the conference both being tools around the GNOME games.

The first talk I delivered was a lightning talk on a code style checker which I wrote for the GNOME games. It is basically a git hook that validates any code style errors the code committer missed. This makes it easier to remember code style, avoids wastage of time during the patch review process for simple(and annoying) code style problems. I encouraged the attendees at the conference to use this style checker to make their first contribution to GNOME by fixing code style in a project they find interesting.

The second talk was a longer and more involved one, titled graph based health analytics on GNOME games. This project is an extension of gnome-continuous and builds a query-able graph of gnome modules, their build status and their dependencies for a said date. The maintainers can then visualize which gnome modules are failing, what dependencies are unique to the gnome modules whose builds are failing, etc. My blog post talks about the project in a bit more detail.

In addition to the talks I helped interested contributors by walking them through our code change process(bugzilla, jhbuild, git), the newcomers page and walked them through a sample code change, building it, seeing the changes in the application, and committing the change locally.

Thanks to the GNOME foundation for sponsoring my travel to attend the summit and special thanks to the local team for setting up such an amazing event!


GNOME Games Health Analytics

This started with Emmanuele’s email on GNOME’s desktop-devel mailing list. Quoting from his email:

In short: we're currently building the core GNOME and some applications every time something gets committed to; we're also doing various tests — like smoketesting the session and running applications — and building VM images out of the build process.

What we need now, though, are "build sheriffs", i.e. people that watch the build process and ensure that it continues smoothly. Ideally,
every maintainer would be on IRC, and would join the #testable channel; sadly, that's not the case. Many are not even on #gnome-hackers, which means they miss the notification that the
something broke the build. We cannot always send emails to the last committer of a broken module because GNOME is a complex project, and a
change in a dependency may indeed break your project, even if you didn't know about it.

I find it almost impossible to be available and tracking the irc channel(#testable) throughout the day and decided to come up with a solution using which I could at least check the health of all the GNOME games once a day.

Visuals always speak better so here goes:

Now its easy to find out what possibly broke a module using some simple queries on a graph instead of:
– going to the gnome-common webpage
– looking for the modules that you maintain one by one
– going to their source on GitHub(incase a module is broken)
– finding out the dependencies and commits
– coming back to the gnome-common webpage to see how the build was a day before and so on.

Though I’m using this for just the GNOME-games, it can be easily extended to all the GNOME applications.

Source code and more information on GitHub/sahilsareen/GNOMEGamesHealthAnalytics!


In this release, the focus was on stabilizing the application, reducing random crashes and improving the user experience.

Quite a few validations were added to handle loading of saved PGN game files.

Of-course, I am proud that gnome-chess doesn’t simply die when you try to start the game with a “Golbat” image!
I enhanced bad PGN load behavior for all the possible fields. For most of the invalid fields, gnome-chess recognizes while parsing the PGN file it displays a warning and takes a corrective action.

Also, if you try to load a PGN which had some invalid moves chess prompts a dialog informing the player of the same and starts a new game. Support for Fischer and Bronstein clock types was added in the 3.16 release. If you had an invalid clock type in the PGN file gnome-chess defaults to the simple clock after displaying a warning and starts the game (much better than crashing on an invalid clock type and being unable to play your saved game, right?).

Some players complained that they couldn’t play against the computer but they actually didn’t have a chess engine installed. So gnome-chess now prompts a warning dialog for this on start-up if you don’t have a chess engine installed.

I also fixed a strange bug when gnome-chess tried to kill some poor random process if it couldn’t launch the chess-engine, well the fix made me laugh!

Michael Catanzaro fixed an issue with several games to fix dragging the game window properly after clicking the game view amongst several other enhancements like build system improvements. Michael and I also pushed several enhancements to the chess-engine.

Johan Manuel added an “Alternate” option in “Play as” to play as the opposite color one played in the previous game.

The translators did a great job of consistently improving translations throughout the release.

Keep geeky and keep playing!

GNOME Games now include the style checker!

I had written about a new git hook I added to gnome-chess in my previous blog post.  I’m pleased to announce that the style-checker is now a part of libgames-support which is a library used internally by all GNOME games .

All the GNOME games can now utilize the benefits of this style-checker by updating their as shown below:

if [ ! -L $srcdir/.git/hooks/pre-commit ]; then

ln -s ../../../libgames-support/style-checker $srcdir/.git/hooks/pre-commit



“It is not enough for code to work.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

A new Git hook to keep the games code clean!

What is a Git hook?

Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. Git hooks are a built-in feature – no need to download anything. Git hooks are run locally. [1]

The new pre-commit hook for gnome-chess!

We now have a new git pre-commit hook for gnome-chess which would get into a games common infrastructure pretty soon!  ^(^

This hook basically checks if your code change complies with the gnome coding guidelines [2] whenever you try to commit. The reason I wrote this is because I also work on projects outside GNOME and it’s really hard to cope up with different coding conventions.

How does it help?

The advantage of this hook is that the reviewers need not worry about looking for nitpicks in the code and can check the logic right away. This would save everyone’s time, and make the review process cleaner and more productive.

Here is an example

Screen Shot 2015-03-10 at 8.44.47 pm

Like it? Want to add this to a project?

Simple! Just 2 steps!

Step-1  Copy over the python pre-commit script[3] to your repository, I chose to make a ‘scripts’ folder and added it in there.

Screen Shot 2015-03-10 at 8.36.58 pm

Step-2 :  Make sure your copies the script over to the git-hooks in your project.

* Read the README[3] for more details.


Special thanks to Michael Catanzaro for his inputs from time to time!

[1]: Git – Git Hooks
[2]: Gnome Programming Guidelines
[3]: GitHub repository: Gnome-Code-Guideline-Checker

3.16 GNOME Chess Updates!

New Features

 Support added for Fischer and Bronstein clocks

GNOME Chess now supports three types of clocks:

  1. Simple
  2. Fischer
  3. Bronstein

Screen Shot 2015-02-22 at 4.59.01 pm

A ‘Timer increment’ needs to be set in preferences menu for Fischer and Bronstein clocks. Each player starts with the ‘Time limit’ set in the preferences menu and may get a timer increment in each move according to the clock type.

1. The simple clock – regular clock where each player switches turn and looses time in each turn equal to the time taken by that player. No timer increments in this case.

2. The Fischer clock – each player gets the specified timer increment (as set in the preferences) before they start their move.
A player might move faster than the timer increment and end up accumulating more time than that at the start of move.

3. The Bronstein clock – each player gets a timer increment at the end of move, but there is a catch!
Unlike Fischer the maximum increment may not be added always. If a player uses more than the specified increment, then the entire increment is added to the player’s clock. But if a player has moved faster than the time increment, only the exact amount of time expended by the player is added.

References: Wikipedia


Miscellaneous Changes

* Fixes/Improvements to :

  • promotion code,
  • loading completed saved games,
  • regressions in pause/resign functionality on timer,
  • time remaining on game restarts,
  • saving completed saved games,
  • undo functionality – resetting the selected piece,
  • precision of chess-clock.

* We set a limit on the maximum amount of time per game in the preferences to 10 hours / 600 minutes.

* Lots of translation updates and source code cleanup.

Happy Gaming!


My GNOME journey!

Sometime around April last year I attended a FOSS conference and found interest in contributing to open source projects.

Deciding on which project to contribute to?

GNOME attracted me not just because I was a happy user but also because of the amazing development tools it has (especially jhbuild!).

Which apps in GNOME?

I love games! So I started off talking to Michael Catanzaro (#mcatanzaro) and he helped me out picking and fixing my first bug in “tali”.

Thereafter, I continued looking for and fixing issues and improving the existing games code.

I’m now one of the primary maintainers of gnome-chess and I’m having a blast!

Help will always be given at GNOME-IRC to those who ask for it!

Looking back its been an awesome journey from attaching my first patch to becoming a foundation member!