Contribute to KPilot

Contributing to KPilot can take many forms. Too many to list them all here, but you could take a look at this list of ways to help (keeping in mind that everywhere that page says "Linux", you should read "a Free or Open Source operating system").

[Money] [Bug Reports] [Webhelp] [Development] [Thanks]

Personally, my favorite kind of contribution is a crisp, concise, well written bug report. One that I can follow. It's even better if I can then reproduce the bug myself. Unfortunately, there are bugs where I just can't do that, and it ticks me off. You could also read my blog entry about receiving patches, too.

For aspiring programmers, there is the notion of a Junior Job to get you started (a kind of apprenticeship), but you should also read the rules of open-source programming for a slightly funny picture of what you're getting into.

Pecunia Olet

 

Ah yes, the ubiquitous "make a donation" button. Personally, I would much prefer you to donate your time or expertise through patches, documentation, or offering useful advice on the mailing list. However, I wouldn't mind being able to purchase a new Palm OS device every now and then (I don't have any connections at Palm that can get me free review units, alas). Most recently I bought a Zire 31 (€ 180) with testing compatibility with OS5 foremost in my mind. That, and I wanted an mp3 player.

In any case, you have my word that any donations made through this PayPal button will go to supporting the KPilot project directly. This means, but is not limited to, the purchase of new Palm units, the purchase of old Palm units, and the mailing of those units to people who need them to make patches for KPilot. I'm probably sending Jörn my m100, since he needs it to test NotePad downloading.

Bug Reports

Sending in bug reports is a tricky business. On the one hand, you have a problem and want to get things fixed quickly. While on the other, KDE releases are few and far between, usually on a regular six-month schedule. That can be a long wait. Not to mention that someone needs to work to fix the bug. Sometimes that's me, but I don't have an enormous amount of time (see below how to solve that). So the trick is first to report the bug in the clearest possible manner, and secondly to find someone to work on the bug.

Clarity: When reporting a bug, make sure you report the model of your handheld, the KDE and Qt versions in use, and the KPilot version you are using. For KPilot versions prior to 4.6.0, you will just have to upgrade first before sending in a bug report, for the simple reason that there is no possibility (for me) to support older versions right now.

So, first version numbers. Then describe the database(s) that are causing the trouble, if any. Provide a log of what KPilot does. Run the daemon from the command line to get a debugging log. Give details. Explain what you expect to happen and what actually happens.

See the FAQ for help with this.

Getting work done: The person with the biggest stake in getting things working (again) is you. I'd like to help, but there are various constraints working against that. This means that in general, the best person to fix the bug is also you, since you have the device and data combination that is causing the problem and you also have the source code.

I realize that invoking "source code" at non-coders seems like a cop-out. Still, you can find a coder in your area who can take a look at it (and if you live nearby, I will stop by, seriously). The logistics of fixing a bug I don't have on an OS I don't run (I run FreeBSD) on a handheld I don't own (I have an m500 and a T|E) for an application I can't use with data I shouldn't access are prohibitive. Again: you have the problem and the test setup ready to fix the problem.

So that's my statement on getting things done: it's best to do it yourself (check out the development documentation below). If that can't or won't work out, then please be patient. I do try to attend to various problems, eventually.

Website

The KPilot website (that's this one) is some simple PHP and a bunch of content. There's nothing really exciting in it. The site is maintained in the same Subversion repository as the rest of the software, and lives on the CodeYard servers.

If you want to help out with the website—and I'd really appreciate a hand with keeping the stories up to date and dealing with incoming bugs and stuff—then you need to get a Subversion checkout of the site and drop me a note with patches (or get a commit bit for it).

That said, advice for the website is welcome (in particular, I'm no great shakes at accessibility for websites).

Development

Development on KPilot is done in a Subversion repository. The repository is hosted on CodeYard, which is sort-of-public. Drop me a note if you need write access to the repository. Anyone can get the sources, though, and work with them at home. Just send me patches.

Getting the website: You need a Subversion client installed to get a copy of the website. It's commonly in a package called "subversion" or "svn" for your operating system.

$ svn co https://cvs.codeyard.net/svn/kpilot/www

Getting the source: You need a Subversion client installed to get a copy of the website. It's commonly in a package called "subversion" or "svn" for your operating system.

$ svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kdepim/kpilot/

For much more development information (what's happening, what's the plan, how to compile stuff, prerequisites, etc.), see the development page. The short story is that if you have the necessary tools (cmake, gcc, KDE) you can just run make and things will work out ok. (See the development page for some more details).

$ make -f Makefile.cmake ... $ make -f Makefile.cmake install ...

Junior Jobs

A Junior Job is a small-to-middling change in an application that need to be done sometime but that doesn't affect the immediate operation of the application. As such, they're usually small features or UI improvements. The KDE Quality Team is a good place to start for information about getting CVS, starting to build stuff, etc.

The list of Junior Jobs for KPilot is maintained in KDE's bug database. You can view KPilot buglist for Junior Jobs. You can also see every KPilot bug ever reported, or just the current bugs. Bugzilla is very flexible. So flexible, that it has its own HOWTO.

Thank You

In order to honour those who put in time and effort to make those small improvements in KPilot, we will try to list such contributors here.