andré klapper's blog.

(Design by Vinicius Depizzol)

It was a hectic day. GNOME 2.32, the last 2.x version, is out now! Big thanks to all the hackers, translators, bugsquadders, documentation writers, artists, marketing folks, ….

Personally I’m proud that our small translation team again managed to have 100% coverage.

The release notes might be a bit boring as most development is focused on GNOME 3.0 (April 2011), and there’s more than quite some work left to make 3.0 the awesome release that we all want to see. And by the way, module proposals period for GNOME 3.0 has started too.

Hadn’t compiled GNOME for a while so I gave it a shot yesterday evening. I ran jhbuild build evolution which should build everything required for Evolution. I had a fresh and empty install directory.
I don’t post this to blame anybody but I wonder how many people give up at this stage and how many potential non-1337h4x0r5 contributors GNOME loses because of such build problems. Teh fun.

gtk+-3 and gtk+:

gnutls-2.8.6:

nss-3.12.6

NetworkManager (branch NETWORKMANAGER_0_7)

sqlite3-3.6.23.1

gtkhtml

avahi-0.6.27

After all I couldn’t build evolution of course (No package ‘libgtkhtml-4.0′ found).
Not very productive, and right now I’m too annoyed to edit the JhbuildIssues wikipage.

The talk (at GUADEC).

Apart from the usual Release Team service announcement and its charming follow-up street fights and the two short Bugsquad and Localization reports at the AGM meeting I also had the pleasure to present a talk about something that I’ve been thinking about for a while:

My theory in short: We lose people that attach patches in Bugzilla to dead modules and never get a response. We waste time translating/localizing modules that will never see a release again. We are stalled as we have always been around 50 “supported” languages for the last GNOME releases. And we need ways out of all this.

For those who could not attend my talk and for further investigation, its slides (pdf/odp), data (cvs/odt) and code (sh) are available. The hardest part really is to find the meaningful data in all that noise. While I plan to continue thinking about this any input is welcome.

The translations (L10N).

For the translations part of my talk, as a first step the Releases Comparison table could get a neater URL and another column that calculates the difference in coverage between the last two years, plus linking the entries in the Languages column against the corresponding teams (yes, teams). Teams that lost more than 10% coverage in the last 2 years are: mk, dz, sq, si, ne, en_CA, cy, hr, fa, vi.
Another data source are those languages with no Git activity (0-2 commits in the last 2 years: an, bal, bem, dv, ff, fur, gn, ha, km, ks, ky, nap, tg, yo, zh_trad, zu; 3-20 commits: en_AU, ha, kk, la, ug).
Contacting these drowning translation teams / maintainers in order to ask for problems or if they still have enough time could for example be handled by the Coordination Team.

In case of no response a translation team can be considered dead.
Now one could take a look whether some contributions exist in damned-lies by people that could be interested to become the new coordinator. And/or downstream teams could be contacted and asked whether they are interested in contributing in upstream GNOME, e.g. teams in Fedora, openSUSE, Ubuntu or other distributions.
While becoming the new translation team coordinator is usually handled quite quickly on gnome-i18n mailing list once it is clear that the old coordinator is not around anymore, changing the assignee data in GNOME Bugzilla and getting Git commit access usually take a bit longer and could currently be demotivating bottlenecks. Time to review the rules or to have a survey about this?

The modules (Git).

For the modules part of it, two warnings could be added to Bugzilla, damned-lies and when checking out via Git for those modules that have not had much activity lately in GNOME Git.

Maintainers of modules that have not seen any commits for a long time (two years?) could be contacted to get a statement about the module’s status (this was done in the past already with mixed results). In case of no answer or a negative answer this could mean “Note: This module is obsolete or abandonned. No work is planned to take place and you might waste your time by filing a bug report or attaching a patch here”.

If we don’t know (yet) this could mean “Note: This module has not seen much activity in the code repository lately” (plus a hint what to do). Of course this first needs a definition for time period and commits thresholds in order to define “not much activity lately”. This could warn patch contributors in Bugzilla to either be patient for a patch review or to contact the maintainer first and it could help translation teams to set priorities and not to translate inactive modules. Another email contact should be provided (probably not the release team but a new team in GNOME?) for the potential case that the maintainer does not respond. However technically I don’t know where the Git activity results could be cached in order to not continiously be queried by several other parts of GNOME’s infrastructure.
As written before, comments, ideas and criticism are welcome. This is still an early stage.

GUADEC (In general).

And to talk in general about GUADEC: As usual it felt like holidays but I finally managed to not spend the entire day at the conference venue in order to also see a bit of the city (like the ICJ, the Scheveningen beach and the city center on Saturday). It was great to have my girl with me and to meet with old and new colleagues of the Openismus crew. And I had interesting chats with Amir H. Moin about datamining and the Evolution crew about non-coderelated stuff, both while lying on a beach couch.

It’s 3 AM, GUADEC is big fun as usual, I’m in the hotel lobby, and as I have only seen one summary blogpost on planet.gnome.org yet I’d like to mention that GNOME 3.0 will be released in March 2011.

Good night.

Quick update of the list of modules (not necessarily complete) that do not yet work with GTK3.

• Note: The table does not cover porting apps to use both GTK2 and GTK3.
• Tickets with background color are blocked by missing GTK+ API.

For a longer list of issues remaining for GNOME 3, take a look at Bugzilla.
Also Migrating to GSettings is required and not covered by this table.