Collaborative Development Tools

Marcus Hardt1 , Ariel Garcia1 , Yannick Patois2 , Ulrich Schwickerath1 {Hardt, Garcia, Schwickerath}@iwr.fzk.de , patois@in2p3.fr
2

Forschungszentrum Karlsruhe GmbH Centre National de la physique Nuclaire et de Physique des Particules e

Abstract Distributed sofware development needs tools to organize the collaborative work. The framework Savannah provides these to a broad community in a convenient way. It is a collection of collaboration and development tools that are accessible via web browser using http. Autobuild is a tool for nightly builds. It compiles a set of packages and presents results on a webpage. This paper describes these tools and some extensions made by the authors in detail. Also we point to real life use-cases, based on the experience of the Savannah and autobuild installation at gridportal.fzk.de and the usage within the EU CrossGrid (IST-2001-32243) Project.

Introduction

The EU project CrossGrid[IST1][CG] is a software development project in the research eld of Grid technology. In CrossGrid the resources and the developers are distributed to 21 participating institutions from 11 European countries. Although the software to be developed within this project is mostly divided up into more or less locally organized work packages, this is not true for every work package and dependencies between work packages exist. These distributed groups of developers need a good set of communication tools, tools to allow testers and users to report issues and bugs with the software and source code management tools. Managers of larger groups need a tool for tracking the status of tasks delegated to groups of people. Some groups also need a homepage and a web page to publish their news on, while the users and testbed administrators need a central point for downloading the compiled software packages. Nightly builds are required for ensuring quality and interoperability of the source code and for providing a standardized build environment. For the communication and source code management part Savannah[SAV] was chosen, because it seemed most mature. Also since it is used for the GNU collaboration portal, longer term support in the future is likely. Savannah is a branch of the former Open Source tool source-forge[VA] by VA Linux Systems. In order to be cost-ecient and extensible the Open Source product Savannah was favored. Savannah does not provide functionality for nightly builds. Therefore the Autobuild tool, developed and used within the European Datagrid Project[EDG] was adapted to CrossGrids needs.

Technology and Structure

The Organizational Structure of Savannah is important to be understood in order to benet most from it. To get a feeling of Savannah we also describe the hardware used for our Savannah installation and the standard software Savannah depends on.

2.1

Organization

Savannah is organized in projects! The main page on gridportal.fzk.de[GP] serves mainly as an overview page for all the public projects hosted. Some of them are shown on the right hand column. Additionally there is one persistent link and tool bar on the left hand side. Among others it oers a search tool. In the central column the latest site news are shown. 2.1.1 Roles and Authorization

The decision whether or not to grant access to a certain tool depends on the role a user plays on the site. Basically there are six dierent roles available, some of which can be taken at the same time. Visitor A visitor is unknown to the system. Thus he can only see publicly available information. This includes news, public forums and bug-tracking information. Viewing the CVS is available, if the project is public. User A user is known to the system via a veried email address. This entitles him to write in public forums and to comment on news items. Furthermore he can now subscribe to a project. Member A user becomes a member of a project as soon as the project administrator has approved his subscription to the project. This gives him access to the private fora and write access to the CVS repository. Only project members can access private projects. Members can also modify the les inside the web and the download areas. The project administrator can assign several roles to members. For instance, in the bug tracker (see chapter 3 for details), a user can be made a Tech to allow him to modify submitted bugs or an Admin to enable him to assign bugs to others and to categorize bugs. Administrator Finally, the Admin is the one who initiated the project. He is responsible for approving members and adjusting their roles. He can modify public information on the projects summary page and enable or disable tools for the project. The Trackers especially the bug trackers need to be customized before they can be used by the project. This is done by the administrator. The administrator can also declare another user as Admin. Therefore there can be multiple administrators per project. Savannah Administrators The Savannah administrators have the responsibility to approve new projects. Furthermore they are the administrators of the machine Savannah is installed on.

2.2

Technology

The Savannah framework is a typical LAMP (Linux, Apache, MySQL and PHP system) system. It was composed and extended out of Open Source tools by VA Linux Systems [VA]. Access to the CVS repository is controlled via ssh. The public ssh keys can be stored in the users preferences. These user preferences and the complete site setup are stored in a MySQL database. To be reliable and responsive, Savannah was installed on a highly redundant dual Pentium III running at 1GHz with 1 GB of RAM. The mass storage consists of two RAID 5 arrays that are mirrored in order to provide a safe storage. This host GridPortal is connected to the german research network provider by a 100 Mbit/s line.

2.3

Autobuild

Autobuild[AB] is completely written in Python. It does not run on a web server, but on one (or more) so called Build Machine(s). These are dedicated machines with a well-dened environment. Autobuild will usually be run as a cron job inside this environment and publishes status information in form of static html les, that are copied to one central web server after every run. The software packages that are created by autobuild are copied to a download repository after every run of autobuild.

2.4

Monitoring

Making sure that the GridPortal services are always available is important to everybody relying on them. This is why we developed the tool GridPortal watcher. It performs frequent checks of key functionality of the basic GridPortal services (net, web, sql, users) and sends emails to the people in charge for the operation if something fails.

Savannah Tools

The Design of Savannah and the various tools will be described here. Since Savannah is project oriented, the tools are available from inside a project. All tools can be reached via the top tool bar (below the project title, see gure 1).

3.1

Project Main Page

Each projects main page is the central point of entry of a project. It is reachable via the gridportal main page or by the explicit URL. It presents the visitor with a short description of the project. If the visitor is logged in he is presented with a button to send a membership request to the project administrator. Below, the main page shows a usage status report about all the tools that are in use by the project. Next to this, the project news are shown. Project

Fig. 1: Main page for a Savannah project on gridportal.fzk.de. news provide a nice way of presenting news about the project. Every news item allows for discussion about it. Technically, this is realized using an online forum. Consequently, Savannah news items oer the same functionality as the forums, especially subscription and mailing list features (see section 3.3).

3.2

Homepage

A detailed description and additional pages about the project can be placed in the project homepage. This homepage is linked right from the topmost tool bar. This link can be changed by the project admin. It is foreseen to integrate a WIKI system into Savannah that can replace or enhance the homepage tool.

3.3

Forums

Mailing lists and Forums are needed to cultivate discussion. Easy sign up and simple browsability can be combined. (See gure 2) The forum is a web based discussion tool using browser technology. Additional email notication can be used to monitor the activities in a forum. We extended the forums, so that answers to notication emails are automatically

Fig. 2: Open Discussion forum of the CrossGrid Integration Team. inserted into the forum. This enhances the forums to browsable archives for mailing lists. In order to avoid spam, only veried email addresses (i.e. from registered users) can send mails into forums. Each forum has a private ag that can be toggled by the project administrator, which makes them accessible by project members only.

3.4

Trackers

Groups that provide a service or develop software hopefully have users using it. They can use trackers to complain about problems to track arbitrary issues. Savannah provides highly congurable and exible bug trackers, simple support trackers and patch managers. They have in common that they are organized similarly to a trouble-ticket system. For each update of a ticket, everybody involved is notied via email. Even users unknown to the system can submit issues in order to keep the barrier for feedback as low as possible. 3.4.1 Bug Tracker

Bug trackers (gure 3) are designed from developers for developers and technically experienced users. Consequently they are fairly complex in conguration and usage. They are mainly used for reporting bugs in software projects. Their exibility makes it possible to congure them for tracking arbitrary items. This depends on how the project administrator decides to congure the various options of the tracker. Also the bug reports can be customized to show only those elds relevant to a certain project. Submitting a bug involves specifying the problem. The user is asked to categorize and group his bug. An administrator can subsequently assign the

Fig. 3: Overview of open bugs in the site conguration at FZK. bug to a technician of the project, change the priority and status and can of course write a reply to the bug. 3.4.2 Support Tracker

Support trackers are more simple. The Admin species a set of categories out of which the user must pick one that best ts his problem. Requests can then be assigned to a responsible technician by a support tracker admin. 3.4.3 Patch Manager

Patches behave identical to support trackers. They were merely introduced in order to provide a dierentiation between patch requests and support requests.

3.5

Task Manager

Task Managers allow to substructure a project. To accomplish this the project administrator rst needs to dene a subproject. Then tasks can be added to subprojects by project members. This involves specifying a start and an end date, alternatively an estimate of hours required to complete the task. Tasks have to be assigned to somebody and given a priority. A task can depend

on other tasks and on bugs. It is also possible to specify a percentage of a tasks completion. This can be used to document the progress of the task.

3.6

CVS

The Coherent Versioning System [CVS] is designed to allow several developers to work on the same les simultaneously! It is based on a central repository. Developers query it for updates on les by others and commit their own changes back. On conicts the developer is asked to manually resolve them. For an introduction to CVS see [CVSDOC]. For a tutorial see [CVSTUT] and for a thorough description of CVS see [CVSREF]. Access to a CVS repository is integrated into many tools like emacs, eclipse or konqueror. The CVS integration of Savannah diers most to what has been installed at gridportal.fzk.de. One requirement of CrossGrid was to have one repository for the entire project. Since CrossGrid is hierarchically organized and Savannah is not, support for this was implemented. A projects CVS section provides usage information on how to check out the projects module out of the CVS repository and points to the proper location in viewcvs. This is an external Python tool that allows browsing through CVS repositories via a web browser. It is the easiest way to understand the directory structure and view dierences of le revisions. It is also possible to search within the les inside the repository and to download entire directories as a tar-ball.

Autobuild

Autobuild[AB] is an important tool for CrossGrid. It allows to build all software packages, developed by developers that are spread across Europe, on a reference platform. Additionally, it performs checks of the dependencies of dependent packages. It provides a means of quality control and uploads the software packages to the download repository. Autobuild was developed within the European DataGrid Project[IST2][EDG]. It is not aliated with the Savannah project.

4.1

Environment

For a build process on this scale it is crucial, to run on a dened standard platform. Therefore, environment variables and versions of the compiler and helper tools have to be well-dened. The actual settings and the installed software are published on a web page. EDG-based Grid Projects will also appreciate that the denition of the build machine is in LCFG[LCFG].

4.2

Building a package

In principle, Autobuild acts like a user when compiling a software: Obtain the software (from CVS), check for the build method and run the appropriate method. Supported build methods are: autotools, congure, ant and

Fig. 4: Latest build results of the CrossGrid Software are published on a web page. make. For a software package that uses autotools, for instance, Autobuild runs autogen.sh; ./configure; make; make install; make rpm and publishes the results of every step on a web page as shown in Fig. 4. The build process is done twice. Once for the HEAD version and once again for the latest available release tag. In case everything was built properly the created packages can optionally be checked for quality requirements, like naming conventions or proper relocatability before they are copied into the download repository, from where they can be installed on a variety of platforms. In case something could not be build, an email is sent to a list of responsible persons. Developers can nd out details about their build process, which is particularly interesting in case it has failed: The package name is a link to the compile log, the tag name links to the CVS repository of the package.

4.3

Documentation

Users need to get up-to-date information and developers need an easy way to publish them. This is accomplished with the two optional targets doc and apidoc, which can refer to running doxygen, for instance. The output of these commands is PDF documents and/or HTML that are published together with all the build information of the package.

4.4

Current Use

Autobuild is currently being used by Crossgrid for building most of the projects software. The builds are run on RH6.2 and RH7.3 using gcc-2.95-2, gcc-3.2.2 is envisaged. DataGrid uses Autobuild additionally with gcc-3.2.2 and also attempts running it on Solaris. This exibility is due to the congurability and to the fact that it is written in python.

Perspectives

Savannah and Autobuild have proven very useful within the CrossGrid Project. Both projects are in a constant ow of improvement. It seems obvious that Savannah would prot from an integration of Autobuild. WIKI pages enjoy a great popularity. Implementing a WIKI system for Savannah using its look and feel as well as the authentication mechanism is under way. The Savannah team also works on improving the trackers. The goal is to generalize the bug tracker to be even more exible. This would allow using the same engine for all trackers. CERN is involved in this development, deploying infrastructure for the LHC experiment. Also motivated by the LHC requirements new authentication methods are likely to be added in the future. AFS based authentication has just been added, support for X.509 is planned. The forums and other extensions made by the authors will be integrated back into the main Savannah tree. If this paper raised your interest in Savannah based collaboration systems you are welcome to visit gridportal.fzk.de and get yourself acquainted.

References
[AB] http://datagrid.in2p3.fr/autobuild [CG] http://crossgrid.org [CVS] http://cvshome.org [CVSDOC] http://cvs.fzk.de/cvs-guide.html [CVSTUT] http://www.loria.fr/~molli/cvs/cvs-tut/cvs_tutorial_toc.html [CVSREF] http://www.loria.fr/~molli/cvs/doc/cvs_toc.html [EDG] http://eu-datagrid.org [GFO] http://gforge.org [GP] http://gridportal.fzk.de [IST1] IST-2001-32243 [IST2] IST-2000-25182 [LCFG] http://www.lcfg.org [SAV] http://savannah.gnu.org [VA] http://sourceforge.org