andré klapper's blog.

This is a short status report at half-time of Google Code-In 2010/11 contest (3 weeks have passed and another 4 weeks to go until January 10th).
Most of the students do an awesome job! Just to highlight some of the tasks that have been finished:

• Translations: Lots of Greek and Romanian translations contributed – Nice boost.
• Marketing: Initial “Getting started with GNOME development” tutorial; Initial guide to Berlin for Desktop Summit 2011 attendees.
• Code: Some gedit plugins ported to libpeas; New gtksourceview languages files (Cobol, Go); Some pygobject patches; Snowy (see Natan’s latest blog post).
• Usability: A survey comparing the keyboard shortcuts of common functions in 15 GNOME applications and the HIG.
• Documentation: Vinagre and gnome-sudoku received initial Mallard formatted user help.
• User Interface: Icon drafts for Anjuta and Vinagre.

Currently 84 tasks are finished, 12 ongoing, and 22 available for students to work on. And we still accept tasks! Click here if you want to mentor ideas that you have, or click here if you want to take part as a student!

Decided to upgrade one of my machines this weekend.
While Fedora’s PreUpgrade is intelligent enough to check the free diskspace on / before downloading the new packages (at least according to the terminal output, bug 649399 states differently) it does not try to estimate if there will still be enough free space to actually extract and install them and will just cancel the process after the reboot (“You need more space on the following file systems: 224 M on /”, whatever unit “M” is meant to be). A bit late.

On / suspect areas to manually clean up are /tmp, /var/cache/yum (some data from older versions around) and /var/cache in general. Biggest packages that could be temporarily uninstalled were webkitgtk-debuginfo, gcc-debuginfo, openoffice.org and eclipse (not needed this time, but maybe next time?).

And apart from quite some typos in PreUpgrade strings (filed a bug) I of course also ran into probably all Evolution bugs that I could:

• Leftover files after migration of config/data/cache to XDG directories
• evolution-2.32.0: Unable to open address book
• Duplicate entry for “Personal” calendar, tasks and notes

But apart from that I think I’m fine.

Google Code-In contest has started on Monday and things are going nicely apart from interpretating contest rules (solved on the gci-discuss mailing list), slowness in task list access (fixed by Google yesterday), and way less email notifications than expected (you have to click the star icon to subscribe to notifications even when you are the mentor of a task).

Big kudos to Lucian Adrian Grijincu for providing lots of useful feedback on how to improve, update and fix the contest documentation on our wiki. I even tricked him into becoming a GCI co-admin for GNOME – Welcome!

We are looking for more tasks!
We only have about 30 so far but lots of interested students. Tasks can be provided at any time, just go ahead!
If you have anything in mind (e.g. translations) that could become a 2-5 days task for high school students please do become a mentor. Check out the instructions and help a student on her or his trip into the open source world!

Good news: GNOME has been accepted for Google Code-In that starts on Nov 22nd!

Now we need your tasks for students, may they be about Code, Documentation, Outreach, QA, Research, Training, Translation, UI. Please take a moment and think about smaller stuff that needs to be done and could help to make young folks dive into open source.
Check GNOME Community: How to Get Involved for more info how to become a mentor, and feel free to contact me if something is unclear or if you need help. (About the tasks already proposed in our wiki: I plan to migrate them to the project’s task tracker in a few days.)

Some might remember Google’s GHOP contest in 2007/08. It will take place again under the name Google Code-In (GCI) from November 2010 to January 2011.

GCI is a “small sibling” of Google Summer of Code for highschool students (13 to 18 years) and with much smaller tasks in several categories (like documentation, code, translation, UI, etc). The average amount of time to be spent for a task should be about three days. See the GNOME wiki for more info.

GNOME community:
If you have an idea about a possible task, want to guide a student to fulfil it and perhaps also want to get new contributors for your project/area, please read how to write a good task and then go ahead and propose your tasks as GNOME will apply for taking part in this contest.

See you around!

(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.