Development Resources

Planner's source code
The source code is stored in a git repository at GNOME's GitLab instance. Anyone can clone it using the following command:
```
git clone https://gitlab.gnome.org/World/planner.git
```
Alternatively, you can download tarball archives of earlier Planner releases.

Planner's roadmap

Issue tracker
Development in Planner is tracked in GNOME's GitLab instance World/planner product. If you are a newcomer, you can find some easy bugs to get started with in this list.

Build instructions

There is a Planner Installation Guide describing how to build Planner on GNU/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

cd ~
git clone git@gitlab.gnome.org:World/planner.git
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:

Find out the name of TAG for the old version you need by looking in https://gitlab.gnome.org/World/planner/-/tags
git checkout TAG
./autogen.sh --prefix=${HOME}/local
make install # will install to the 'local' directory in your home directory
export PATH=${PATH}:${HOME}/local/bin
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:

git checkout master
meson --prefix=${HOME}/local build
ninja -C build install # will overwrite the currently installed version in the 'local' directory in your ${HOME}
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.

Planner

Project management