Managing an Open-source Project 

When you are talking about software development and hope you are serious enough, which you will be, in most cases, you will definitely need someone to use your product (the user), someone to track and give feedback for the product, someone to help you throughout your development phase (co-developers). That's why we generally tend to define a business model when starting on some new project so that we have all these components handy in case a need arises. For this, we design a core development team, a set of beta testers, a set of marketing and management teams and sometimes a sponsor who will fund the project.

But if you're developing an open-source project, then the ball game is slightly

different. For instance, here you generally don't own a company with in-house software developers and in case you do, you might be willing to get some of the development and bug fixes done by external contributors. And that's where the charm of Open Source lies. You share your code with everyone so that it can get re-checked and modified quickly. But for this structure to work properly you will need something which can automatically manage the development versions, bugs and automate the build process. In this series we will broadly look at the options in the open-source world to solve these issues. And later on, we will go into details on each and every topic on what all you need to start hosting and managing an open-source project. Here we talk about some of the commonly

available applications and tools and then we will see how we can implement one of them. That is

Bugzilla.

Bugzilla: The most important thing that you need after the completion of a software project is a proper bug tracking and

managing solution. So that everyone using the software can easily report bugs, check for the bugs already reported and see whether some solutions for the bugs are listed or not. For this, we have a classic open source

bug-tracking software called Bugzilla. This is even used by most large open-source

projects such as Mozilla, Mandrake, etc. You can directly download it from www. bugzilla.org and if you have an updated machine then installing Bugzilla means just unpacking the tarball and running the checksetp.pl file. Next month we will see how exactly you can build and deploy your own Bug Tracking Server using

Bugzilla.

Installing Bugzilla the easy way



Installing Bugzilla in the traditional manner is not very easy because you have to resolve lot of Perl, Apache and MySQL

dependencies. But there is an unofficial installer created by Arne Schirmacher with which you can install Bugzilla by running just two or three commands. Isn't that easy?

We tried it out on a custom installation of PCQLinux 2005 SP1 with Apache, MySQL and PERL pre-installed. And the package worked perfectly.

So to begin with you have to download the unofficial Bugzilla installer from 'http:

//www.softwaretesting.de/download/bugzilla-installer-1.4.tar.gz'. The file size is around 25 MB and if you can't download it because of any reason, just wait for the next month's PCQuest CD, and we'll give it to you. Copy this file to your home directory and run the following commands to unzip and untar it.

#gunzip bugzilla-installer-1.4.tar.gz



#tar —xvf bugzilla-installer-1.4.tar

Now cd into the newly created folder Bugzilla-installer and open the file called 'build' in any text editor. Now take a look at the paths and parameters used in this file. If you are using PCQLinux 2005 SP1, the

default settings should work without any problem but if you are using any other distro then you may need to modify the paths a bit. After reviewing the paths, save the file and exit the editor. Now you have to create a MySQL instance for Bugzilla. For this run:

# mysqladmin --user=root --password=your-password create bugs



# echo "grant all privileges on bugs.* to bugs@localhost" | mysql --user=root —pass word=GEHEIM mysql

Now you have only one thing left to do. You have to run the build file to start the

installation process. To do so, run

#./build

This process will take around 15 to 25 minutes depending on the speed of your

system but all configuration steps will be taken care by this. When the installation process completes, you will be able to

access the Bugzilla interface at http://localhost/ bugzilla or http://yourservername/ bugzilla. Wasn't that really easy?

Next month we will see how we can customize Bugzilla for your specific needs and also see how to implement CVS for your software development project.

Anindya Roy

Automake

Generally when we talk about open-source software, it becomes quite obvious that it will be used on hundreds of Linux distros, Windows, BSD, etc. This means that we need some mechanism that can automatically build and compile the Source of the Software to the specific platform in which it is

been used. It not only makes the life of the end-users easier but also reduces the hazards of manually re-compiling and building the software by the
developers. 

But to achieve this degree of flexibility we have to follow certain standards. And for this we have a set of tools called

Automake.

CVS

CVS or Concurrent Version System is a version control system that has been developed in the GNU world by many people starting from 1986. Currently, CVS is maintained by Cyclic Software, and you can visit

http://www.cvshome.org/top know more about it. Using CVS, you can record the history of your source files (normally text files). The best part about CVS is that 

instead of saving every version of every file, it stores only the differences

between the versions. This helps in faster uploading and downloading of the new versions as the amount of file size is comparatively lower. CVS also helps you if you are working in a group on the same project. CVS merges the work when each developer has done his work. CVS also allows you to isolate changes onto a separate line of development, using a technique called branch. When you change files on a branch, the changes do not appear on the main trunk. Later you can move the changes from one branch to another branch (or the main trunk) by merging the contents.