andré klapper's blog.

Just dropping some recent activity here.

• Olav, Allan and I wrote the GNOME 3.2 release notes. They are available for translation and will soon be available to public.
• Sent two GNOME 3.2 blocker bug reports and asked for committing reviewed patches.
• If you plan to have a GNOME 3.2 release-party, add yourself to the list on the wiki!
• Next step: Prepare a release schedule for version 3.3…

At the first Desktop Summit in 2009 KDE’s aKademy and GNOME’s GUADEC conferences were just co-located. I cannot remember having had any interaction with non-GNOME folks (but I wasn’t around for the complete conference).

In 2011 it wasn’t just co-located but mixed tracks. Though I attended some KDE talks and had to realize that most were boring to me simply because I have nothing to do with that software stack I still had great and interesting conversations with some KDElers.

Mission

The Summit website states “The goal of this event was to share ideas and further collaboration between the two communities.” The section “Goals for this year” also lists “Collaborate on desktop software projects”. And everybody has different experience and opinions whether this actually happened or not.

Criticism

In both communities there are mixed feelings whether the concept of a Desktop Summit makes sense. I know that some GNOMErs expressed their opinion that Desktop Summits slow down GNOME development. You can draw two conclusions from this: Either to not repeat Desktop Summit because of that. Or to fix this for the next Desktop Summit.

While the technical stacks are mostly different, there is room for collaboration in less technical areas such as release management, bugsquads or documentation efforts – even if it’s only about exchanging experience or best practices. This also applies for some technical areas that are shared in our stacks via freedesktop.org, e.g. parts of the accessibility framework.

So?

If the fear is that planning and development in each environment slows down under the collaboration banner, and that a GUADEC-only conference is more helpful in pushing things forward in GNOME, why not have it both? Have one or two days of collaboration related sessions only and nothing GNOME or KDE (or LXDE) specific, followed by two co-located conferences that only have environment-specific sessions. Does that make sense?

Disclaimer

I left out the financial part on purpose as I have no clue about that, however I know that it has influence on the decision whether to continue Desktop Summits or not.

As Tiffany already mentioned in her blog post, Pedro and me hosted a Bugsquad BoF at Desktop Summit. There were not too many folks around (mostly the people from the previous session stayed in the room) but nevertheless it was very interesting as blauzahl was kind enough to answer lots of my questions about KDE’s bugtriaging processes.

No groundbreaking stuff to post, but it was an interesting insight.

• KDE Bugzilla has the Voting feature enabled. GNOME Bugzilla has not. I’m rather neutral about this so I was just curious.
• In KDE, bug reports of unmaintained or deprecated modules can be closed as RESOLVED UNMAINTAINED (though this is not done consequently), while GNOME Bugzilla uses RESOLVED WONTFIX combined with a “gnome[unmaintained]” Status Whiteboard entry for this. I like the idea of a separate resolution though I don’t remember if RESOLVED UNMAINTAINED is used for KDE3 apps that are dead, or KDE3 apps that have a KDE4 replacement, or both.
• Currently no community has bugdays (GNOME, KDE) which traditionally are an easy way to get new people involved (outreach) in the projects as many bug triagers move on to writing code after some time in the Bugsquad. Ubuntu has topic-oriented bugdays every week and uses them mostly to clean up the bug database of specific modules. The “Triaged” status in their bugtracker (Launchpad) helps avoiding duplication of work.
• Remaining question that was also a topic in the previous BoF in that room: Where to share patches, especially for long-term distributions (RHED, SLED, LTS) && projects that are unmaintained in upstream development (e.g. KDE3-only components or deprecated GNOME2 components), and how to improve upstreaming efforts. One idea was to use Bugzilla’s “Default CC list” option for downstream packages to get notified of patches (but bugmail options don’t have a “trigger for patches only” setting).
• Speaking about statistics in general (and as I am impressed by the MeeGo Community and Activity Metrics), efforts in KDE seem to be very similar to those in GNOME, namely Quarterly reports and a Commit digest, but nothing targetting the bigger picture either.

(Copyright: Dženan Šehić; CC BY-NC-ND 2.0)

I’m late with commenting Desktop Summit in Berlin as I spent the last week offline in France and fifteen minutes of it at the mayor’s (La mairie) to afterwards celebrate the wedding of an old friend and great artist. Plus French food was awesome as usual…

One particular pleasure I had at Desktop Summit was to present together with half of our team our proposal for hosting next year’s GUADEC conference in Brno (CZ) to GNOME’s Board of Directors. We had a well-prepared bid in place (mostly thanks to Jiří Eischmann‘s hard work). I congratulate the A Coruña team and their impressive proposal for making it in the end!

Comments by board members after their decision on the bids, plus Stormy’s blogpost were particularly helpful to understand how tough decision making can be.
When you work on a proposal there are many areas to cover. Our team considered the geographical aspect (there has never been a GUADEC in Eastern central Europe) as one of the main arguments. However the members of the board obviously are individuals having differing priorities. Stuff like centralized accomodation and a large get-together area at the venue likely had a bigger weight this year than e.g. the region or accomodations covering different budgets. Please note that this is no criticism but rather a potential pointer for next year’s teams.

However if my impression was correct, more preparation might be the one thing that I wish for next year’s applicants: With regard to a few questions we received while presenting which were already covered in our proposal paper published weeks before, it felt like some board members had not read it closely before. Times might be busy, but in case proposals are not really read everybody could save some time next year.

Last but not least, a big “Thank you” to all those people that spoke to me after the decision was announced telling me that they had looked forward to going to Brno next year. See you in A Coruña!

I’m in Berlin for a conference. And I am sleepy, so this will be short.

• I write this every time I am at a conference, but still: I’m thankful to meet many friends in our community again, plus great new people.
• Most interesting talks were those explaining how to build a toaster from scratch (Thomas Thwaite) and the perception of architectures (Federico Mena). Also liked vɛ̃sɑ̃’s talk.
• I agree with Jos Poortvliet.
• Claudio Saavedra is a pretty good karaoke singer.

Last year I had the megalomaniac idea of rewriting the user documentation of GNOME Evolution from scratch.

As GNOME 3.2 approaches quickly I had to realize that perfect is the enemy of good. After putting the remaining TODOs into the random categories FIXLATER, NEEDHELP, MUSTFIX and DONTCARE and after having no MUSTFIXes left, I merged the new User Documentation today into the codebase. It will be available on library.gnome.org from August 17th on (that is when the next tarball 3.1.5 will be released), and while a few pages could still be improved I can at least promise that nothing is worse than in the old manual.

I’ve mostly failed to attract contributors but I welcome everybody to fix any remaining issues by searching for TODOs in the checkout (how-to), to translate the new docs to your favorite language, to file bug reports about stuff that is improvable, and to buy me some icecream or beer at Desktop Summit Berlin tomorrow. Or next year in Brno in case our proposal will be successful. Cheers!