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!
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!
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 git.gnome.org; 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.
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.
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.
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 autogen.sh as shown below:
if [ ! -L $srcdir/.git/hooks/pre-commit ]; thenln -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
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. 
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  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
Like it? Want to add this to a project?
Simple! Just 2 steps!
Step-1 : Copy over the python pre-commit script to your repository, I chose to make a ‘scripts’ folder and added it in there.
Step-2 : Make sure your autogen.sh copies the script over to the git-hooks in your project.
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. Thesimple 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.