Escrúpulos Una piedra en la conciencia del software libre, calidad y la vida misma

Oh my. Poor Dave Neary. He was just trying to offer some insight into how GNOME gets put together, and it ends up serving as an outlet valve for some pent-up frustration towards Canonical, in this case via a blog entry by Greg DeKoenigsberg.

Perhaps Dave's presentation could have been a bit "safer" if it had looked at just more recent times, or covered more than just commit rates, but presentation time is limited and, really, any information on how your community works and is put together is invaluable to its health and improvement. If I were part of the GNOME community, I'd be looking for ways to embrace Dave's hard worked for information in positive ways.

Dave's intentions were undoubtedly good and he put an obvious amount of time and effort into his presentation, but was repaid with a very public and unflattering flame war about something rather tangential to his goals with that presentation. Ouch.

Tribalism

Why does this happen? That's a great question, and I'm not sure we can ever have all the answers with perfect accuracy. Maybe we can summarize and approximate, though, and discover useful things as a result. Mark Shuttleworth offers that the problem is tribalism, and that tribalism in the form of fanboyism is Bad(tm). I think Mark hit the heart of the matter.

Here's an unfortunate part of the truth, though: while Mark rightfully comes out against tribalism, Canonical has, in my experience, been as much a part of fostering tribalism in F/OSS as anyone else. In fact, I'd say they are right there among the leaders in doing so: it's a side effect of their immense drive to build a rabidly loyal community around their brand and their propensity to try tell other communities how to do things (e.g. how to schedule their releases).

After all, it's pretty meaningless to be a self appointed dictator for life if you don't have a kingdom to dictate, right? (That's said with my tongue placed firmly in my cheek. :)

Those are rather tribalistic concepts, though, and it is reflected in choices such as Canonical's decision to use launchpad rather than upstream repositories that already exist or how we see Ubuntu LoCo's displacing more diverse Linux interest groups at the local level. It isn't zero-sum, though: Canonical has their reasons and there are benefits that come along with the challenges. I even believe that Canonical's motivations are not conspiratorial in nature, but are similar to those that drive rest of us: making F/OSS awesome. I also recognize that mistakes get made, in spite of those good intentions. Most importantly: Canonical isn't alone in this set of interactions. We are all part of this thing.

If you are an Ubuntu or Canonical fan (or Mark :) and you read that, it might sting a bit (or maybe even a lot) and the instinct might be to react quickly, negatively and loudly. After all, who the hell am I to say something like that, right? :) Instead, maybe we can step back for a moment, turn off the flamethrowers for a little while (there's lots of time and opportunity to use them later if we wish to ;) and really think about the root causes of our tribalism. Much of it is going to turn out to be innocent, but all of it will show where we have room for improvement.

On Being Able To Admit Failure

One thing I've learned in my travels as someone who dabbles from time to time in providing leadership is that in doing so your faults will be put on display for everyone to see. We are each imperfect, we all screw up from time to time and being front-and-center means our screw ups get put front-and-center, too. It is humbling. It can be important to recognize when it happens and (even if it takes a while) come back and go "yep, I screwed up, let's see how we can improve on that going forward..." At that point we all grow and become better people for it. If we do that within our Free software communities, our communities will also become better for it. Linus' ability to do that makes up for many other faults he may exhibit from time to time.

Someone asked me the other day on the kde-promo list how KDE people can expect to get the KDE branding terms "right" when even I don't always get it right! I responded with the most honest answer I had: I still, even now, make mistakes when it comes to the branding terms, in large part because I've been doing the "KDE thing" for so long that it's like an old dog with new tricks. I asked them to continue to point out when I get it wrong so I can improve. It's often hard to say things like that without hedging, especially for those of us with hard heads and big hearts.

I've also discovered that, sadly, I'm going to offend or let down those I love dearly from time to time even though I really don't mean to and don't want to. When that happens, it's often more important to just say I'm sorry without worrying about defending what I did, even if I think it was a misunderstanding or justifiable. I have been working for many years on being able to prioritize the well being of those I care about more than I do about being "right". Let me be honest: it doesn't come naturally to me, and I still fail at times. But ... I also do manage to say "I'm sorry", to look for root causes without looking for blame to attach to it, and most importantly to me: to try and work on improvements that address root issues. I keep trying to remind myself: "I am an imperfect man reaching for the unattainable goal of perfection; and I am inching closer to never getting there every day."

Ok, so what's my point, already? Well ...

When Mark wrote about tribalism, Máirín dredged up in the comments section an unfortunate and regrettable public gaffe on Mark's part from the past and asked him if he'd apologized for that yet. Maybe Mark should consider doing just that, even if he doesn't consider what happened to be wrong in his own mind. It could help drain away some of the poison out there that is used to fuel some of those tribal fires. It certainly can't hurt.

In fact, all of those who have pointed fingers or defended themselves loudly, including (but certainly not limited to) Greg, could maybe try to step aside from their own correctness and ask what are the shared root causes that lead to this state of affairs. Can we instead create discussions with ourselves and with each other that reach for understand but don't include statements of blame or accusation? It is possible to discover the mechanisms of failure in a relationship and come up with new possible solutions to try in blame-neutral ways.

That's just another way of saying that others may be responsible for (a large or small) part of the current dynamic, but we don't need to use that as an excuse to sidestep responsibility for the roles we play in it or as a way to avoid addressing the issues altogether. After all, what's more important: the moral high ground in our own little kingdoms of "Me, Myself and I" or forging a stronger and unstoppable thing together?

On Being Part Of The Problem Solution

The good news is that when we are one of the people caught up in a problem, intentionally or not, we can be part of the solution. Yes, being part of the problem is an opportunity. To illustrate: we may not have invented proprietary software ourselves, but we are/were caught in the midst of the consequences of a world that was dominated by proprietary software; by writing Free software, we are creating part of the solution to the negative effects of that situation.

In the questioning of Canonical's contribution, right now I see a lot of people trying to make the case that they aren't a part of the problem or that others are more a part of the problem than they are. Quite clearly they axiomatically are all shareholders in whatever failure is happening (the flamefest itself is a failure, imho). It is axiomatic because the problem is being driven by how communities are interacting, and the people pointing fingers and making defenses are part of those communities. Some are even responsible for leading the relationship components of those communities. They could be identifying what the challenges are and being part of the solution, regardless of who is contributing what to those challenges in the first place.

If each of the parties (GNOME, Canonical, Red Hat, whoever else) involved took internal stock of the situation they might identify all kinds of things they can each do to improve. How much better than writing witty blog posts that won't alter the status quo that would be! Leadership will be self-evident when people start describing and implementing such improvements, regardless of whether others do so first, later or never.

On Alignment

Starting with the alignment of priorities and agreeing on the context for the conversation would be a reasonable place to start, perhaps. To illustrate what I mean by that: Jono Bacon
used the term "upstream" in his response to the issue in a way that is very different from what the people leveling the complaints at Canonical are. Jono used upstream in terms of Canonical's own efforts: their software developers are upstream of their packagers. However, it seems evident to me that Greg and others are using the term in the context of the global F/OSS economy, where in this case GNOME is the upstream of Canonical. It's the difference between looking at the supply chain within one particular company's factory, and looking at the role of that factory in the greater economy in which it operates.

Due to this difference in context, people are engaged in a conversation about upstream contribution in which both are 'right' in terms of the context they have chosen to speak from. This also means, though, that neither party is really addressing the same issue together. As long as those kinds of context and priority differences are not addressed so that a common conversation can be had, it will be a very long, hard, painful and probably unfruitful conversation.

I've been caught in many such conversations in the past with others in F/OSS. It happens; it's also fixable.

Why Care?

I believe it to be important that we care about these things because they are doing large amounts of unintended damage to F/OSS. But as my step-father used to tell me, "When you point a finger at someone else, you are pointing three fingers back at your own self." (Try it: point at something with your index finger, arm extended. :)

So let me address those three-fingers-pointing-at-myself. To be honest: the relationship between KDE and Canonical has not always been fruitful or friendly, ditto for KDE and Red Hat or KDE and GNOME. Even within KDE we have our moments of discord. It's not easy, it's not simple and I do not want to come off like I'm pretending it is or that my or KDE's track record is perfect either. KDE has managed to improve many of these things, some of them immensely though certainly not to perfection, but you know what is really unfortunate and sad when I reflect up on that? The root causes, tribalism and selfish misalignment of priorities relative to each other, were / are the same as those at the heart of today's tempest in a teapot over Canonical's upstream contribution and/or lack thereof. F/OSS has yet to truly learn the lessons we need to. We keep repeating the same unhealthy behaviors, we keep enabling each other in doing so.

I have to say that it was really tempting to delve into an analysis of what, in my opinion, the specific behaviors are that led to this particular blog storm, but when I thought about it I realized that it's not really my place to do so. After all, I'm not a direct stakeholder in this particular scenario and have not been invited to enter into the middle of what amounts to other people's relationship. So instead, let me get a little philosophical about what it might take to step away from our feudalistic ways:

We ought to be looking for F/OSS communities who can lead in demonstrating positive and useful ways of dealing with these somewhat inevitable moments of conflict. We need to encourage those who aren't leading in this way to improve their game; we need to give each other the opportunity to improve our game by avoiding blame games. We need to support each other in our hard times and our moments of brilliant alignment. For those who insist on tribalism, the rest of us need to move past them and minimize their impact and importance in the F/OSS ecosystem, so as to limit the harm they perpetuate.

We need to learn how to accept that someone is going to be a fan of $DISTRO or $PROJECT without using that against them. We need to learn how to be a fan of $DISTRO or $PROJECT without looking for ways to push for its advantage at the expense of F/OSS in general. We need to learn to recognize each others strengths, as well as to stop claiming that we're strong where we aren't. We need to learn to disagree without sabotaging each other. We need to learn how to cooperate, even sometimes by making local compromises to achieve a higher level of global win. We should be looking at how to put together what we are each doing well into a larger whole, even when we are also competing elsewhere. We can both compete and cooperate without dragging each other down in the process.

The path beyond tribalism is, in my humble opinion, to realize that despite our love for KDE, GNOME, Ubuntu, Red Hat, Suse and/or fluffy bunnies we must each hold aloft a common goal that trumps all else: F/OSS must succeed. The world is depending on us to do that, because the world needs Freedom, and Free software is an important part of that.

That is the challenge we have before us. Sort of puts things into perspective, doesn't it?

But Before I go ..

Kids are smart. They will learn that when you do something bad you get attention even if it is negative. If they don't get the attention all children need in the course of growing up, they put this together in their head and start to look for ways to break "the rules" to get that attention. To be fair, some adults do that too. :) As an adult who plays a role in the child's life (a parent, especially), that pattern can be prevented by (among other things) paying attention to the things they do that are positive.

In that spirit, I'd like to end this blog post by giving a shout out to a few of the communities out there that are doing good things. Good work deserves attention and recognition, and you shouldn't have to be in the middle of a controversy to get it.

I'm thinking of OpenSuse, for instance: they make hard decisions and are pretty open about how difficult things can be internally at times, but they've consistently been a pleasure to work with, even through difficult times.

I'm thinking of Pardus, a small but hardworking group of people making an awesome distribution aimed primarily at their own region, but who are also doing all kinds of wonderful things technology wise both in their project and upstream.

I'm thinking of Red Flag who, despite other possible negatives, have also been contributing more and more upstream over time.

I'm thinking of Mandriva who, despite their financial bumps over time, have not only never caused grief for us as an upstream project but have contributed significantly.

I'm thinking of the numerous small and medium size businesses who aren't distributions but who are as important as many of the distros in making sure upstream keeps ticking. I'm also thinking about you, reading this blog entry because you care enough about these issues to do so with an open mind.


p.s. I'm concerned, having re-read it (and edited it several times), that this blog entry could come across as preachy. I really hope it doesn't, but I do recognize that my communication skills have limits to them and some may choose to read it that way. It feels rather unsafe to push the "Publish Post" button, and honestly I am hesitant to do so. It seems, however, that these are things that need to be said, and I can only hope that some of it is useful and gets through to those who will make things better than they are now. Deep breath time!

Love and with hope for all the best things in life, Aaron.

Unfortunately I haven’t made any blog updates in awhile. I’ve been very busy between work and school (and I will likely spend this weekend working on a 20 page project that I’ve written 0 pages for ;). That doesn’t mean I have nothing to report though…

First off, I have renamed kdesvn-build to kdesrc-build to reflect the fact that it builds from Git-based software repositories. In conjunction I released kdesrc-build 1.12 which has various minor improvements, including a few Git improvements.

I’ve complained about my car breaking down. It’s fixed, although I will be selling it now (my wife and I were debating the merits of getting an improved car for awhile before, this incident sealed the decision).

Just today I’ve committed a new feature to JuK, the sadly neglected KDE Software Compilation music manager. Now you can use the scroll wheel in the track announcement popup to quickly switch tracks without having to use the Next/Prev buttons. It’s probably already in every other media player with a playlist, but it’s at least in JuK now. Note that this is a 4.6 new feature, not 4.5.

I’ve also been “reviewing” a patch to further remove Qt3 support code from JuK, which I will try to clean up and get comitted this release cycle. The big thing I still need to do is to finally convert from K3ListView to a real Model/View architecture to finally be rid of Qt3Support. Help is always appreciated btw =D

Burkhard Lück, the documentation super-hero, has been improving JuK documentation for me, but I still need to make some changes that he’s requested to bring the docs closer to 2008-era (let alone 2010) :(

That’s another good “intro to KDE Platform” kind of job by the way, it’s how I got introducing into coding for JuK myself. ;)

Thank you for your reply!

I unset the homepage options and the program opened my file!!! Thank YOU!!! I ran a consistency check. The problem was, as my research showed, with a scheduled transaction. Deleted that, and the software works very well now.

Have a great weekend!

Nathan

Looking for a good way to contribute and got some spare time this weekend? KDE BugSquad is holding a Bug Day revival this Sunday 1st of August and still looking for people who'd like to help out with getting Dolphin bugs under control.

We'll be gathering in our IRC channel (#kde-bugs) starting around 10:00 AM european time zone. As always, no coding skills required. All you need is a recent version of our beloved KDE Software Compilation. Senior bug triagers will be around to help you get started.

More info on: http://techbase.kde.org/Contribute/Bugsquad/BugDays/DolphinDay1 (available soon)

See you there! :-)

Can't make it then? That's ok, we'll have another. Promise.

But feel free to drop by anytime, bug reports always come in, and somebody has to look at all those duplicates!

Then the big question: do we hold our Bof in the back of a bus next year too? It makes it hard to take a group photo!

As many of you know, the KDE Project is transitioning to using Git with Gitolite and CGit. As such, I thought I’d update my aging Gitweb/posix-permissions installation of git to use CGit and Gitolite, and now my public git repository is kicking away. (If you’d like commit access any place or would like to host your own repo on my server, drop me a line.)

Since Gitolite manages git repositories, it has the option of generating the necessary information for Git’s shipped gitweb. This includes making a static list of repository names that should be included in gitweb as well as optionally adding the gitweb.owner entry inside .git/config and the description file at .git/description. The static list of repository names is boring and standard and easy. The owner and description specifications are standards set by the Git project for this kind of information. Hence, Gitolite supports interfacing with them.

Meanwhile, CGit uses its own configuration format for determining the owner and description and repository path. For interfacing with Gitolite, in the past I have created a hook that writes out a CGit-formated configuration file, which is then included in the main cgitrc with the include directive. Essentially I had to do this:

gitcode@starfox ~ $ cat web/cgit/generaterepos.sh #!/bin/sh   cd $(dirname "$0") rm -f repos.tmp   cat ~/projects.list | while read gitname; do name=${gitname%.*} fullpath=/home/gitcode/repositories/$gitname owner=$(git --git-dir=$fullpath config --get gitweb.owner) desc=$(cat $fullpath/description) ( echo repo.url=$name echo repo.name=$name echo repo.path=$fullpath echo repo.desc=$desc echo repo.owner=$owner echo repo.enable-log-filecount=1 echo repo.enable-log-linecount=1 ) >> repos.tmp done   mv repos.tmp repos   gitcode@starfox ~ $ tail -n 1 web/cgit/cgitrc include=/home/gitcode/web/cgit/repos   gitcode@starfox ~ $ cat repositories/gitolite-admin.git/hooks/post-update.secondary #!/bin/sh exec /home/gitcode/web/cgit/generaterepos.sh

This worked decently, but it was cumbersome and ugly, and was likely not to scale as features in both Gitolite and CGit are added and changed. Luckily, CGit supports the scan-path option, which builds an internal list of repositories automatically by scanning a directory for git folders. One such solution for integrating with Gitolite would be to simply point scan-path at Gitolite’s repository directory. This works fine, but it has three main shortcomings, which I’ve addressed this in a generic non-Gitolite-specific way in three patches. Let’s walk through them one by one.

projects-list

We don’t want all Gitolite repositories showing up on CGit, and Gitolite provides a generic mechanism for controlling this: it writes a list of all the repositories selected for Gitweb to a file called projects.list. It’s just a flat file with each repository’s name written on a new line:

CheeseWhiz.git Geoemail.git MyCoolThangs.git

So, what about augmenting CGit’s scan-path feature with another setting called “project-list” that points to this file? That’s what this patch does. If project-list is set before scan-path is set, then scan-path only scans the git folders at project-list/${a line in the project-list file}. Problem solved, and this is a pretty generic way of doing it too.

git-suffix

Most people store git repositories on disk at MyGitRepository.git. Notice the .git ending. However, most people prefer to see it listed as just “MyGitRepository” and they especially would like to clone it at gituser@domain.com:MyGitRepository, without needing the .git ending. Usually, CGit’s scan-path infers the repository name directly from the folder name. This patch adds a setting called “remove-suffix” that, if set to 1 (default is 0) before scan-path is set, will remove the .git suffix from the repository name and url while still pointing to the correct physical path. This as well is fairly generic and not specific to Gitolite or Gitweb, but rather Git’s usual conventions.

config-owner

CGit’s scan-path infers the owner of the repository from the posix owner’s UID name. But there is an additional Git standard for overriding this for any interface: the “gitweb.owner” configuration key in .git/config, which Gitolite understands and respects, as well as Gitweb. This patch simply calls Git’s internal C functions for fetching this information from the current repository’s config, and prefers this as the owner to the posix owner’s UID name. If gitweb.owner is not set in the configuration, it falls back to the posix owner’s UID name. This is a standard Git behavior. This occurs only for scan-path — cgitrc specified owners are preferred over these former two, obviously. Again, this configuration standard has been determined by the Git project, and both Gitolite and Gitweb respect it. So, this patch adds support inside CGit for it.

it works

Now instead of the include and the ugly set of scripts and hooks, I can just place this at the bottom of my cgitrc:

remove-suffix=1 project-list=/home/gitcode/projects.list scan-path=/home/gitcode/repositories

and this integrates perfectly with Gitolite. All is harmonious in the Git universe.

On top of all this, I’ve cooked up a wicked good .htaccess file for CGit that allows me to have anonymous http pull at the same time as it rewrites the CGit urls to be pretty. Check it out:

Options FollowSymlinks ExecCGI   DirectoryIndex cgit.cgi Allow from all Order allow,deny   RewriteEngine on   SetEnv GIT_PROJECT_ROOT=/home/gitcode/repositories   RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule "^(.*)/(.*)/(HEAD|info/refs|objects/(info/[^/]+|[0-9a-f]{2}/[0-9a-f]{38}|pack/pack-[0-9a-f]{40}\.(pack|idx))|git-(upload|receive)-pack)$" /git-http-backend.cgi/$1.git/$2 [NS,L,QSA]   RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^.* /cgit.cgi/$0 [L,PT,NS]

A strange combination of stopping internal redirects and partial rewritings and odd stop conditions has made it so that the request gets forwarded and reformatted to git-http-backend if and only if it is first valid with cgit.cgi. Is this crackable? Can anyone figure out a backdoor to grab a repository that isn’t in projects.list?

I’ve also written a super generic script for uploading new repositories to my gitolite/cgit installation. From a git working directory, I run ~/Projects/uploadNewGit.sh "This is a description of my new git repo.", and wham-shabam, all the permissions get set and everything is uploaded just fine. Here is uploadNewGit, the latest version of which you can always find in my GitTools repository:

#!/bin/sh   GITOLITE_ADMIN="$HOME/Projects/gitolite-admin"   gitdir=$(readlink -f "$(pwd)") name=`basename "$gitdir" | cut -d / -f 2 | cut -d ' ' -f 1` description="$1"   if [ ! -d "$gitdir/.git" ]; then echo Not a git repo. exit 1 fi if [ -z "$description" ]; then echo You need to specify a description argument. exit 1 fi   pushd "$GITOLITE_ADMIN/conf" > /dev/null echo "Writing config..." (echo echo " repo $name" echo " RW+CD = $(whoami)" echo " R = @all" echo " $name \"$(git config --get user.name)\" = \"$description\"") >> gitolite.conf git commit -a -m "Adding $name to repository." git push popd > /dev/null   url=`git --git-dir=$GITOLITE_ADMIN/.git remote -v | grep push | cut -f 2 | cut -d ' ' -f 1 | sed "s/$(basename $GITOLITE_ADMIN)/$name/"` git remote add origin $url git push origin master git push --all git push --tags

(As a side note, I’m not really sure the best way to quote commands inside of commands with variables that have spaces. something=$(command $(othercommand $argument)) has issues if argument has a space or if othercommand produces something with a space or if command produces something with a space (not totally certain about the latter two — I should check). But I can’t do this: something=”$(command “$(othercommand “$argument”)”)” because of obvious quoting problems. What’s the common solution to this? I’ve been using an awkward combination of the backtick operator `…` and the $(…) syntax but the backtick has some weird rules too. What’s the deal? Can somebody point me in a good place to read about this?)

Anyway, most of what I’ve written about in this post is new to me. Or at the very least, I’m a bit uneasy. So if you have any suggestions, by all means please tell me. I’m looking forward to seeing what the KDE sysadmins do in the end. Hopefully the CGit authors accept my patches.

Update: After some back and forth with Lars, the CGit maintainer, I’ve added a few more patches, including putting the gitweb.owner functionality behind configuration setting and also caching the scan, among various other improvements. You can check out all the commits I’ve made on this at the cgit for my cgit clone.

As has been mentioned before, start KMyMoney using the option -n. That prevents opening the file. Next turn off all options available for the homepage. Then try to open the file. Does it still crash? If not, run Tools/Consistency check.

There's a reference to an account which does not exist (anymore) and that is causing the problem. We've had these reports before and they all were related to a reporting issue.

Hope that helps.
____________________
ipwizard, proud to be a member of the KMyMoney forum since its beginning.
openSuSE 11.1 32 bit, KDE 4.3.5 and openSuSE 11.0 64bit KDE 3.5.10, kubuntu 8.10 32bit KDE 4.3.2 via LTS

Thank you for your response! I'll clarify a bit. The crash happens when I attempt to open the data file. The progress bar at the bottom moves over until the readout says "reports," then the crash happens with the pop up window. I have moved the data file to other computers and have had the same result!

Nathan

See you all there next year

It's official the combined KDE Akademy and Gnome GAUDEC conferences will be held in Berlin in 2011, next year and this is great news! I played a small part in organising the joint conference in Gran Canaria in 2009, and really enjoyed working with the Gnome guys most of whom I hadn't meet before, as well as the familiar KDE people. It was great fun to see how it turned out. I don't think anyone really knew in advance - we didn't know if too much collaboration would spoil the 'community bonding' aspects of the conference and their individual identities. Or maybe too little collaboration would increase the distance between the two communities. In the end I thought the collaboration aspects could have been better, indeed like the WiFi could have been better - there is always something you can improve at these conferences, but what the heck, by and large it was mostly pretty good.

I enjoyed being able to go to both presentations, and some of my favourite ones, like the MeeGo^h^h^hMoblin user experience talk in the mobile track, came from the Gnome side. Both projects are facing the problem of how to you merge your desktop technology with the upcoming Smartphone/Small devices that run platforms such as Android or Meego.

A consequence of stresses like upstream vs downstream or mobile vs desktop, is that Dave Neary's recent survey of Gnome contributors has given rise to much discussion and flaming about Canonical's contribution. One from Mark Shuttleworth called Tribalism is the enemy within, which is worth a read. That addresses tribalism within the Gnome community, and that is clearly a bad thing.

Another good post from Jono Bacon RED HAT, CANONICAL AND GNOME CONTRIBUTIONS included this from Dylan Macall, which made a good point:

"..This whole thing is really putting forwards an issue Gnome has right now: they can’t, as a community, decide whether they like the idea of external projects building new environments on the Gnome platform. (Case in point: Meego for netbooks).
I think there’s one camp that thinks Gnome should be a user-facing product, with its own special branding and its own distinctive look that everything ships in pristine condition. (I’ll inject my opinion in brackets here: I think that entirely defeats the purpose of having multiple distributions).

Then there’s another camp that sees Gnome as a starting point with lots of handy tools (and common modules) for distributions to build operating systems. For example, Unity, Meego, Jolicloud, UNR…
That first camp sees Gnome as a monolithic project; only internal work is worthy. The latter camp sees Gnome as something akin to Gnu.."

I think you could have exactly the same discussion about the KDE project and what it's relationship with MeeGo should be. Does KDE consist of a lot of useful tools and libraries that we should encourage as many other projects as possible to use? Or should we concentrate mainly on a cohesive desktop experience? Are the two aims incompatible? I don't know..

I hope we can minimise Gnome vs KDE tribalism too, and I'm looking forward to another combined conference, where we can integrate the communities better (and in the process have great parties involving much beer drinking of course). I was slightly disappointed that Gnome 3.0 has been delayed, and I really wish them good luck in getting it out of the door. It is not true at all, that if Gnome does worse, then KDE will do better. If both projects succeed it is more like '1 + 1 = 3' or if one project fails it is '1 + 1 = 0.5'. We now have much infrastructure in common and need each other to succeed so let's "Relax"..

Since the C# bindings are apparently not really used/wanted by anyone (except for some Windows people – but that’s really not my main development platform) I thought that maybe some more people are interested in Java bindings.

There was a poll on kdedevelopers.org two years ago that showed Java ahead of Ruby and C# – but it doesn’t seem to be really representative: there are at least some Ruby plasmoids on kde-look.org, but none in C# (which was still ahead of Ruby). Given that Trolltech/Nokia abandoned QtJambi I’m not too sure about Java bindings either.

So I’m asking the community directly before I start putting too much work into a project that noone really wants: So far we have (active) bindings projects for Python, Ruby and Perl – is there any demand for Qt/KDE Java bindings in the community? Or if not for Java, for any other language/platform?

Looking forward to your comments

Dion just made new release counter for 4.5.

Just add a HTML/JavaScript gadget to your blog:

For the square banner:

<a href="http://kde.org/" target="_blank"><img src="http://e2-productions.com/countdown/counter45-square.php" alt="KDE SC 4.5 Release Counter" /></a>

For the long banner:

<a href="http://kde.org/" target="_blank"><img src="http://e2-productions.com/countdown/counter45-long.php" alt="KDE SC 4.5 Release Counter" /></a>

Plasma has a wonderful theming engine, that enables the creation of a really stunning visual appearance, with a great amount of customizability, just look at what is available right now, to not mention that being vector based makes the widget set pretty flexible and able to be used on really different hardware form factors with different sizes and dpi.

But we're developers and we like to write code, hack on stuff, we often forget to document things, and this is an area that really can get better.

Yesterday I've forced myself to look at the quite incomplete and outdate documentation for the Plasma theme system and I've looked file by file, element by element and completed and ordered the whole theme.

Now if you have any doubt on the Plasma theme structure, just go to the relevant techbase page, and you'll find the complete list of every file and every element in every file, updated to the upcoming 4.5 release. this should ease a lot the construction of themes.

It has been a long and painful work, of which developers may really want to avoid it, but it incredibly pays the effort, because it's a really important part of the elegance we are trying to reach. A complete, pretty and documented framework is what is elegant to a quite relevant part of our audience: developers that are approaching the platform for the first time.

Now we are restructuring the techbase page for Plasma, moving here the pages that makes more sense here, having the two wikis more in focus and comprehensible.

If you are interested, if you are trying to approach the development in Plasma and have difficulties to grok some of the concepts, if you already work on some plasma aspects such as plasmoids, just stop on #plasma on freenode and you can give an hand in the documenting effort, being tutorials, wiki pages or API docs, you'll learn quite a lot of the internals in the process and will make easier for others to learn.

Which plugin are you using? libOFX or AqBanking?

Which version of KMymoney are you using?
____________________
Hei Ku, proud to be a member of the KMyMoney Development Team since January-2008

Hei Ku wrote:How come you only get a single account when defining the OFX profile?

Well, two accounts exist, but the tool only shows one. As suggested above, it could be because the account number listed is an employer account, not an employee account number I think the gui lists the account it found when connecting to the financial institution, not the accounts to be mapped.

if you start kmymoney2 -n and it crashes, that's because the installation is hosed. The '-n' switch means it doesn't open a file. So, the problem is not in the file but in your install.

Reinstall, update or upgrade, depending on your distro.
____________________
Hei Ku, proud to be a member of the KMyMoney Development Team since January-2008

You can have updates for different accounts.

How come you only get a single account when defining the OFX profile?
The payee shouldn't matter, the issue is that if you select your account, the updates will go to your account.
____________________
Hei Ku, proud to be a member of the KMyMoney Development Team since January-2008

The Plasma team tries to care about documentation. We always fall short of our own high expectations, in part because they are high and in part because we don't have a technical writer in the project. What a difference just one technical writer as a Plasma team member would make!

Still, we have quite a bit of documentation around. This includes API docs, examples and Techbase tutorials. I'm quite proud of the comprehensive documentation we have for things like the desktop scripting, Javascript API and Theme contents (thanks to Marco for updating that one today!) as well as the growing number of examples we are adding.

We have, however, been committing two sins: we've been abusing Techbase as a project community wiki and we haven't been writing end user documentation. We're fixing that, but before I go into details I'd like to point you to Dominik's excellent reminder-by-blog regarding the mission of each of KDE's public wikis. To quote the summary from that blog entry of his:

• TechBase: The primary place for high quality technical information about KDE targeted at 3rd party developers, ISVs and system administrators.


• Community: The working area for the KDE community. It provides a place for sharing information within the community and coordinating community teams.


• UserBase: The home for KDE users and enthusiasts. It provides high quality information for end users on how to use KDE applications.

Community.KDE.org
So everything we have had under Projects/Plasma on Techbase really is supposed to be on community.kde.org. We started, and are very nearly complete, that transition. You can see the results on community.kde.org/Plasma. We've used this as an opportunity to freshen up and reorganize some of the content.

If you are involved in a project that has content under techbase.kde.org/Projects, please also consider moving it over sooner rather than later. I did a few pages a day (so that I didn't get bored by it ;), spending no more than 30 minutes or so at a time doing so. Marco also pitched in with the Theme Details, which has now moved to being a tutorial and out of our community coordination wiki space. So it's very doable, you just need to budget a little bit of time. Best part is that it taxes no brain cells, so makes a great end- or beginning-of-day task for when you'd like to do something KDE but can't bring yourself to do any heavier lifting. :)


All Hail KDE User Documentation Writers!

Next up is user documentation. While in Finland for Akademy 2010 I made a personal commitment to Anne Wilson, one of this year's Akademy Award rockstars, to write user documentation on Userbase for Plasma. It's not quite as selfless as that may sound at first. You see, there are those who would like to see Userbase become the new spawning ground for end user documentation.

This is due to the fact that there are, and have almost always been, just a small group of absolute heroes who have worked on KDE documentation through the years. They have done an awesome job with the resources they have to work with. In fact, one of the key players thus far in documenting apps based on the KDE Platform v4, Burkhard Lück, was also recognized with an Akademy Award this year. There is only so much a small group can do, however, and our software moves quickly. In addition, our users are more and more web-centric when it comes to looking for information.

Wouldn't it be great if we had a way for more people to participate easily in adding to KDE user documentation? How about providing our documentation in a more familiar web format as well? Enter Userbase, a mediawiki-driven site that may just be a key part of the answer. It has a passionate and committed project driver behind it as well in the form of Anne.

The goal is to therefore put more and more user documentation on Userbase where it can be groomed and improved into stunning user documentation. There may be some nay-sayers who think that user documentation is a work of art (and I agree to an extent) and requires skill to do well (again, I agree). The issue, however, is that it's too difficult for those with the skills and sense of the art to get involved. That difficulty is in part perceived ("how do I contribute?" is such a common question) and in part real (barriers not low enough). Remember that many people said the same thing regarding art and skill about encyclopedias and maps. Turns out this kind of content creation does work pretty damn well. Hello, Wikipedia. Hello, OpenStreetMap.

Realizing The Dream

For this dream to enter reality, though, several things were needed. Translation is a solved issue now from what I understand (kudos to those who got that going!), but still outstanding was the ability to generate offline versions of the contents of Userbase so that we don't require going online every time you want some documentation about a KDE application. There was the intent and the desire to work on this, and even a good start to it.

So I decided that out of respect for our users and for the work people were putting into Userbase that I should put some of my own skin into the game as well. So I told Anne that if they got the offline creation of the documentation working that I'd document on Userbase how Plasma Activities work from an end user perspective.

Well, guess what Anne and her co-conspirator Ingo Malchow have managed to do? Yep, they've got automatable offline document creation of Userbase content figured out. There's a remaining issue of whether to use an online service that exists outside of KDE for this, or to set up our own installation of the same (Free! :) software on one of our own servers. That's an implementation detail, though. The hard work has been accomplished in my opinion. Which triggers my commitment.

So I will soon be starting to work on Plasma documentation regarding Activities on Userbase in the Desktop area. I also plan on tidying up the organization of the content that is already there as I go. It will take me several weeks, I imagine, to complete this task. I also hope that by throwing some of my energy into it, that it will encourage others to follow suit. Particularly those amongst our users who are reasonable writers; and remember: if you are concerned about your English skills, it's a wiki .. we can help fix errors if/when they appear. We appreciate content added to the point that it wouldn't even cross our minds to think poorly about good content that happens to have a few English mistakes. We also will need the English content translated so that we can offer this much needed documentation to all of our users across this blue marble we live on together.

I'll keep you all updated regarding my progress and what I learn as I go through it. Anne and I also discussed the possibility of doing Documentation Days, similar to how we used to do Techbase Days (which would be nice to start up again as well) and the very successful Bug Days.

(Speaking of which, did you know that Bug Days are starting up again? Yep! Next one is the 1st of August, so be sure to mark it on your calendar and show up for some bugtastic fun. :)

When walking in a big group of people you have to check every now and then for the slower ones so you don’t leave them behind and lose them. It’s the same in a community like KDE. Every now and then you have to check if everyone can still keep up and if not take the necessary steps. That’s why for the second time now I’ve asked KDE developers to tell me which parts of KDE they think really needs some new blood or more helping hands. This is the list of answers I got:

• KDE bindings needs a maintainer for PHPQt and some helping hands for Qyoto/Kimono (the C# bindings). – contact kde-bindings@kde.org
• KDEPIM looking for someone to work on Akgregator and the Kontact shell. – contact the kde-pim mailing list
• Juk could benefit from a port to actual KDE Platform 4 technologies (away from KDE3 Support and possibly port Bangarang’s Nepomuk storage to Juk). – contact the kde-multimedia list
• KOffice is in need of people poking Karbon and Kivio. – contact the koffice mailing list
• KCalc, KFloppy, Kdf, KTimer and Sweeper from kdeutils do not have maintainers at the moment. Most of these applications are almost unused, but they haven’t been excluded from the module and might at least provide some fun to newcomers. – contact kde-utils-devel@kde.org
• Okular could use some help fixing crashes and finishing features. – contact aacid@kde.org
• UserBase is looking for people to help improve documentation. Tasks and guidelines are available on http://userbase.kde.org/Tasks_and_Tools. – contact annew@kde.org

Quite the mix – surely there’s something exciting in there for everyone. So if you are someone who wants to contribute to KDE and looking for a place to start or an experienced contributor looking for a new project, this is where your help would be really appreciated. Choose your direction and get your hands dirty

If you were a participant of this years KDE multimedia meeting I would be interested in your opinion:

As you probably know this was the second kde meeting I organized and I plan to do another one next year (btw I got today the OK of a certain person and I think this means the topic for next years meeting is set but more about this in the following weeks). What do you think if I would earn some money with the organization of the next meeting.

As I like or love to organize such meetings and I doesn’t seem to be that bad in this I’d like to organize another and another and … You see ;-). But even if it’s a lot of fun it’s also work and time consuming work nonetheless. For the meeting this year it took a good month of time to organize everything (incl. the meeting time). The whole amout of time is or was distributed over half a year.

And the other thing is that I need to eat (;-), pay the bills and as I’m moving to my girlfriend and my studies end in the next year or two a family is not that far away. And that’s another reason I’d like to professionalize the meeting, make a conference/sprint out of it. An annual one. And don’t missunderstand me: I’d don’t want to become rich on the shoulders of kde developers and/or the KDE e.V. The contrary I starting to plan and search for sponsors much earlier this time to decrease the amount of money the e.V. "needs" to sponsor.

Oh and if or when you’re waiting for my next "kde work day" blog. It’s in the making but as I’m moving (the whole room is full of stuff to package some stuff delays a bit. And there’s anoher idea floating in my mind. Something somehow kde related but not code related and something for the kids and probably something to play and something about Konqi the dragon but …

Oh and I’ll do something like (yes, I like the word "something" a qt and kde course in my local linux user group… Oh and this is the last oh: I’ll do an english course in the next semester to meliorate my english grammar. Hopefully to your pleasure as well ;-).

Hello,

today i will show you a new plugin for Kate, called KateSQL.
As you may have guessed, it brings to Kate the basic features of an SQL client, allowing you to open connections, execute queries, and display result data from SELECT statements or stored procedures.
Since this plugin makes an extreme use of the Qt Sql module, most of database drivers are supported..

Said this, let me explain how it works..

First of all, you have to create a new db connection through a simple wizard, specifying driver, connection parameters (hostname, username, password, etc…), and a descriptive name, that KateSQL will use as identifier.
Done this, what you need to do is just select the query text in the editor and press F5 (or your preferred shortcut). The whole text will be executed through the selected connection.

For SQL output, two toolbox are disposed in the bottom area:

• The first will show messages returned from the server (errors in red, others in green, like number of affected rows).
• The second contains a table view with a custom model associated, to show resultsets of a query. This custom model does nothing more than a QSqlQueryModel, only provides colors and formatting for each cell..

Ah, about this, my last commit implements a configuration widget that let you choose colors and font styles for text fields, numbers, blobs, nulls, booleans and dates… cool, yeah?

Last but not least, on the left panel you can find a basic and useful schema browser, that show the tree schema of the database connection currently selected. With this tree widget you can browse through tables, system tables and views, up to individual fields. obviously, primary key fields are distinguished by the classic yellow key icon.

Currently, there are few problems with multiple query handling.. Some engines doesn’t supports it natively, others can receive queries separated by a semicolon, but the QSqlQueryModel can handle only one resultset at time.. probably the best solution is to parse the text, split queries, and execute them separately.. Surely, this feature will be implemented soon.
Stay tuned!

Of course, if you want to help us with development, you are welcome!