QOT

General

Being quite busy with my full-time job at PrimeBase Technologies and quite limited in time for QOT development I was looking for ways to optimize the process around QOT.

I came to a conclusion that instead of preparing and releasing milestone binary releases it will be more optimal to declare the main project trunk to be the permanent release place and “release” the new features and bug-fixes by simply pushing them to the main trunk. This way I will be able to make individual features and bug fixes available as soon as possible. So

to install QOT for the first time you do:

1. install Bazaar

2. run “bzr branch lp:qot” from the shell to get the latest stable QOT sources

3. follow the usual QOT build/install procedure

to update to a new version:

1. run “bzr pull lp:qot” to update sources to the latest stable version

2. follow the usual QOT build/install procedure

Below I will point out the most important consequences of this model.

Code stability

Code stability will not degrade in particular because QOT is quite a small project where most of the testing is automatic and running the full test suite even daily is easy. In fact the “average” code stability should even increase as the new bug fixes will be available as soon as they are implemented!

Binary builds

This is something I cannot do very often, just because currently this process is manual. However this shoudn’t be a problem for Unix/Linux users where GNU C compiler is available by default. On Windows I use MS Visual Studio. You will need the free version of the IDE and Windows SDK 6.0.

I’m still planning to do binary releases but on a more rare basis, depending on the amount of newly added code/bug fixes.

Bug tracking, Feature Requests and Participation

Launchpad has convenient facilities for submitting bug reports and feature requests. You are encouraged to use them to report bugs/make feature requests. Bug fixes can be tracked by binding bug reports to source branches.

For those who considers adding some custom features to QOT Launchpad offers a very flexible parallel development model which is very well exalained here:

part 1
part 2

Basically you can either fork the trunk and maintain your own version and periodically pull updates from the trunk or do the full cycle by proposing your changes back to the trunk.

Final Word

I hope these changes will help optimize the QOT development process, improve the quality and increase development dynamics. Your questions and suggestions are welcome!