Planner development

Reporting bugs

Planner uses GNOME bugzilla to track bug reports.

Source code repository

Planner's source code is maintained in git.

To check out a copy of the latest source execute the following command:

git clone git://git.gnome.org/planner

If you have push access to the git repositories, you might want to use the following command instead:

git clone ssh://USERNAME@git.gnome.org/git/planner

If you would like to browse the source code in your web browser, please visit http://git.gnome.org/cgit/planner/.

Build instructions

There is a Planner Installation Guide describing how to build Planner on Linux that should also be helpful for building Planner on other UNIX-like systems. Instructions for building Planner on Windows are also available.

Getting involved

We are looking for more people to join the development team (so much to do and so little time ;-)). The first thing to do when you want to get involved is to subscribe to the mailing lists and preferably join the IRC channel. Feel free to ask any questions that pop up while browsing through the code.

Submitting patches

Here are some tips on creating and submitting good patches:

• always create a patch relative to the latest git master
• if you make white space changes, keep them in a separate patch. This will keep the functionality patch small and readable, while the white space patch can be easily verified to be nothing but white space changes (diff -w)
• make sure your changes do not generate compiler warnings. Fix the problem that the compiler warns about, don't just suppress the warning.
• before submitting the patch, read through it to see if it only contains the changes you planned to include (no unintended white space changes, no left-over debugging code, no new functions that you thought you were going to use but didn't after all, ...)
• if the patch is over 40K, please put it somewhere where people can download it and send a link to the patch instead

• either mail it to the planner-dev mailing list or preferably submit a bug report and attach the patch there (you can only attach files to a bug after it has been submitted)

• use git format-patch to generate the patch. Make commits for each logical steps or consistent set of modifications and don't be afraid of using git rebase -i before submitting your patches. Try to keep balance between too big patches and too many patches.

Other ways to help out

If you'd rather not start hacking right away, there are other ways to help out. One is to find bugs that have been solved, but have not been marked as FIXED in bugzilla. To identify those you must first find a reliable way to reproduce them with an old version (the version the reporter used) and then go through the same steps with the latest version from git to show that the problem doesn't occur there.

Getting your copy of the source code

1. cd ~

2. git clone git://git.gnome.org/planner

3. cd planner

You only need to do this once. The following steps may then be repeated for each report you want to work on.

Reproducing the problem

Try to reproduce the problem with the same version as the reporter:

1. Find out the name of TAG for the old version you need by looking in http://git.gnome.org/cgit/planner/refs/tags

2. git checkout TAG

3. ./autogen.sh --prefix=${HOME}/local

4. make install   # will install to the 'local' directory in your home directory

5. export PATH=${PATH}:${HOME}/local/bin

6. planner

Checking if the problem has been solved

Once you figured out how to reproduce the problem reliably, try to do the same in the latest planner version:

1. git checkout master

2. ./autogen.sh --prefix=${HOME}/local

3. make install   # will overwrite the currently installed version in the 'local' directory in your ${HOME}

4. planner

If you see that the latest version does not exhibit the problem even though you followed the steps that triggered the problem 100% of the time before, then you should add a note to the bug saying that it can be marked FIXED. Also describe the steps you took to reliably reproduce the problem if they are not clearly mentioned in bug report already. In fact, adding them to a bug report that lacks this information is always useful, regardless of whether the bug is still present in the latest version.

Getting the latest updates to the source code

Once in a while, when developers have pushed new commits to the central repository, you can do git pull in your clone directory to get these commits.

What's next?

You can check out the roadmap.