HWQ Project Plan
- Anil Aliyan <acaliyan at gnvfc.net>
- Scott Hughes <sonicscott9041 at gmail.com>
- Eric Shubert <ejs at shubes.net>
- Martin Waschbuesch <martin at waschbeusch.de>
To create a source rpm package that contains everything needed to install the Horde Webmail software on an existing Qmailtoaster installation.
While QMT is supported on multiple platforms, development of the initial release of HWQ will be limited to the latest CentOS 5 platform. Other platforms will be added subsequent to the initial release. Care will be taken during development to make notes of platform specific aspects to aid in this subsequent phase.
This phase produces the project plan, which is essentially this wiki page. It identifies the project team members, the project goal, and the major milestones of development.
This phase produces the detailed requirements document, which elaborates upon the project goal (stated above). The requirements state in fair detail what it is that's to be done, but not how. This includes, but isn't necessarily limited to:
- Which features of horde webmail to include
- (vanilla horde-webmail tarball vs. custom install)
- How the toaster package will relate to the horde packages and patches
- (leveraging horde team releases, augmenting configuration)
- What the installation process will accomplish
- Install the dependencies
- Install the tarball
- Setup the database backend
- Setup apache config
- Set desired config options
The design phase uses the requirements definition as input, and produces specifications for how the various requirements will be satisfied. This includes, but isn't necessarily limited to:
- Paths to use for horde components
- (ensure horde can be run side by side with squirrelmail, etc.)
- backend to use for data
- configuration options for horde components
- (e.g. enable HTML preview for eMails, etc.)
The construction phase is all about coding and unit testing. Note, sometimes some design aspects that are undefined are determined during this phase. The bottom line output will be rpm specs, which entails some spec-specific coding in addition to a healthy dose of bash scripting. It's often best to develop a manual prototype, which is then automated using rpm specs.
This phase conducts full integration testing. This includes not only the installation of the package, but basic testing of the operation of horde as well. A testing procedure should be documented, if not automated to some degree.
Beta versions will be released to the community. Once we feel that everything is stable, a GA release will be made. Mechanisms for distribution will be decided upon when the time comes.
The Construction through Release Phases will be repeated for each additional platform that is supported by QMT.