PIM/KPilot: Difference between revisions
Bbroeksema (talk | contribs) (New page: = KPilot Development = Pilot development is distributed and collaborative. That means anyone is allowed to -- and encouraged to -- help. We use a revision control system called Subversion...) |
Bbroeksema (talk | contribs) |
||
Line 27: | Line 27: | ||
=== Getting the latest stable version: === | === Getting the latest stable version: === | ||
The most stable and tested version of KPilot exists in this long-term, stable branch of KDE's SVN repository. As bugs are fixed in KPilot, the latest, bug-fixingest code will be found here. This branch includes what is provided in KDE's 4.x release cycle, plus any bug fixes in between KDE's release cycle. It should always be safe to retrieve and use this code. | The most stable and tested version of KPilot exists in this long-term, stable branch of KDE's SVN repository. As bugs are fixed in KPilot, the latest, bug-fixingest code will be found here. This branch includes what is provided in KDE's 4.x release cycle, plus any bug fixes in between KDE's release cycle. It should always be safe to retrieve and use this code. You can get it from the command line as follows: | ||
$ svn co svn://anonsvn.kde.org/home/kde/branches/KDE/4.2/kdepim/kpilot/ | $ svn co svn://anonsvn.kde.org/home/kde/branches/KDE/4.2/kdepim/kpilot/ | ||
=== Getting the latest development/unstable version: === | === Getting the latest development/unstable version: === |
Revision as of 23:18, 23 January 2009
KPilot Development
Pilot development is distributed and collaborative. That means anyone is allowed to -- and encouraged to -- help. We use a revision control system called Subversion to make it possible to work together on one code base. KDE as a whole uses Subversion as well, and has a Subversion guide for KDE which describes basic SVN (Subversion) usage. There is of course also the SVN Book which covers everything. You can fetch the sources to KPilot as described below, and then compile them. This will always give you the latest version of KPilot. Such a version may not be the most stable, since I may be in the middle of fixing something big and complicated. Such is the luck of the draw. I'll try to post a warning on the site beforehand, though. Once you have the source, you can compile the latest version of KPilot with debugging enabled (it is enabled by default) in order to get the best possible debugging logs so you can track problems down effectively. In general, if you have a problem with KPilot I will expect you to have a copy compiled from source to work with -- it's the only way we can get anything done.
== Road map ==
This road map is a list of "what's on my mind for the short and medium term" items; they may not be done in order, and critical bugs might get in the way at any time. Please get ahead of me! Send me patches for any of these items and receive a real KPilot cookie (recipe undisclosed).
- Top priority:
- Detection wizard is broken (probably from threading).
- Use CUDcounter to warn user of large changes (data safety).
- Enhance backups (with datestamps, for instance).
- Valgrind until clean.
- Code cleanup:
- get full sync working with memofile conduit (oops!)
- pull all syncing logic out of conduits into a common base class and leave only data transformation/comparison stuff thar. Note: we have a good base for this code in trunk/KDE4, and it'll happen there, not in the 3.5 branch.
- The daemon needs a pop-up log viewer window, and kpilot needs to have its hotsync code removed. All the config stuff should end up in the daemon, so that KPilot is just a viewer for data.
- Development in trunk:
- Need to find areas of base conduit and keyring conduit where syncing is not working and bullet-proof/fix them.
- Unit tests need to be the New Way Forward (TM). Any code fixes should include unit tests. Testing should first be done via unit tests and only after that tested via a live Palm device.
- Category syncing has never worked from PC->Palm. We MUST get this figured out and working in an extensible manner.
- Instead of spinning our wheels in trying to convert all of the old conduits from kde3/qt3->kde4/qt4, I think it would be better to convert less code and extend all conduits from our new base conduit code.
Get the source
The source code for KPilot lives in a Subversion repository. You will need a Subversion client to get it (there are no downloads of the KPilot source available right now). How you get a Subversion client is rather system dependent; something along the lines of apt-get install subversion or pkg_add -r subversion should do the trick, though. Once you have SVN, you can use it from the command line to download the KPilot source. It is recommended that you get the latest version, as described below, but there may be other versions available, such as the latest version deemed stable, or whatnot. These can be found in the different tags and branches in KDE SVN
Getting the latest stable version:
The most stable and tested version of KPilot exists in this long-term, stable branch of KDE's SVN repository. As bugs are fixed in KPilot, the latest, bug-fixingest code will be found here. This branch includes what is provided in KDE's 4.x release cycle, plus any bug fixes in between KDE's release cycle. It should always be safe to retrieve and use this code. You can get it from the command line as follows:
$ svn co svn://anonsvn.kde.org/home/kde/branches/KDE/4.2/kdepim/kpilot/
Getting the latest development/unstable version:
The latest version is known as "trunk" in SVN jargon, and the development of KPilot for KDE4 happens in KDE's subversion server, in trunk. This code is very possibly not as functional or well-tested as the above branch, being that it's the unstable and development environment for KPilot. You can get it from the command line as follows: $ svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepim/kpilot This will download the source into a directory called "kpilot/". You can rename the directory however you like. Once you've got the source code, you can cd into the directory and compile it (or hack on it). Keeping up-to-date: Once you have a checkout of KPilot trunk (released versions never change, so you don't need to keep those up-to-date), you can keep up-to-date by running SVN update every so often, like this: $ svn update Do this in the directory from the KPilot checkout (i.e. in the kpilot/ directory). This will download whatever changes have been made since last time. Once you have the source, you can do almost whatever you like with it within the rules of the license. In particular, I'd suggest you compile it, so that you can run the latest version.