Sebastian Schaffert

Jan 28 2009

KiWi System – Current State

Published by wastl at 20:20 under KIWI

As we have now set up a new “Nightly Builds” system, I take the opportunity to describe the current state of the KiWi development environment and provide you some links. Please use the facilities we provide as much as you can.

Generally, the latest updates to the KiWi software development environment are always documented under http://wiki.kiwi-project.eu/?title=kiwi:Software

1. Task and Issue Tracking (Jira)

We have task and issue tracking set up for quite some time now. Unforuntely the system is currently only used by some of you, therefore
I’d like to encourage you to use it more. The Jira system is available at http://wiki.kiwi-project.eu/atlassian-jira

We use Jira not only as a bug-tracking system, it should be used in the following situations:

bug reports; everytime you spot a problem that you cannot immediately fix yourself, write a report categorised as “Bug”; ideally, you would also write a TestNG integration or unit test that demonstrates the bug, or at least provide a code snippet or stack trace that illustrates the problem.
ideas; when you have a (concrete or visionary) idea for the KiWi system, you can use Jira to make a short note for everyone to read; please categorise such reports as “Idea” when you are asked
tasks; when there are concrete tasks that are still open, you can also create a “task report” by selecting the “Task” category. Tasks are meant as things that are still to do, so you can use this feature as a task/todo list, either for yourself or for all of us.

Notice that you can subscribe to the Jira system using RSS (even filtered by certain queries). This gives you the possibility to always monitor the list of issues.

2. Repository Browsing and Version Control

The KiWi development environment also offers “Crucible and Fisheye”, which can be used for getting an overview how the source code of the
system evolves and who did which changes. In Fisheye, you can browse the differences of each revision of the Subversion repository, or you can
display the revision history of files or directories. Fisheye provides a very nice user interface for displaying who changed what and which line
of code is attributed to whom.

Fisheye is available at http://wiki.kiwi-project.eu:8060/ ; please take the time and play around a bit with this tool (no login required) – it
can be very useful at times.

3. Nightly Build System (NEW!)

In the last days, we have also finalised the new nightly build system. What it does is the following:

it checks every 20 minutes (not nightly) for new revisions of the source code
for each revision, it tries to compile the source code, runs all unit and integration tests, and creates extensive test reports
test reports are then published under http://wiki.kiwi-project.eu/nightly/kiwi-tests/ for each revision.

Internally, I already call this system the “whom to blame” system, because it immediately shows you who broke the system. Which is of
course a bit unfair, because some of you are working more on the heart of the system while others are working more on the edges, and test
coverage is currently not very good.

For the nightly build system to do its work properly, it is absolutely necessary that everyone who develops source code also writes appropriate
test cases for verifying that this code works as expected. If you don’t know how, learn to do it – look at the tests we have already written, it
is not that hard. There is also documentation for this on the Web.

You can verify that all tests are running by running “ant doTest” in the KiWi directory. Please never check in source code into the repository
that does not pass all tests – with one exception: when you encounter a bug that you cannot fix, please write a test case that demonstrates the
problem so that someone else can more easily reproduce the issue and fix it.

4. Open Source Release

One of the major milestones of WP3 will be the release of a first Open Source version of the KiWi core system, which is our main goal for the next weeks (until beginning of March). Open Sourcing is a crucial step for KiWi, because it is supposed to help us attract external developers. On the other hand, Open Sourcing requires high quality code, good documentation, and a good development environment. Another plan is to
make KiWi “self-hosting” until March, i.e. to move the current IkeWiki installation to the KiWi system.

The concrete tasks until March are: