Summary

Checkbox has fragmented over the past several cycles as different audiences find use cases for it. We should find a way to reduce or eliminate this fragmentation so that we have the minimum number of Checkbox packages required.

Rationale

Different audiences have found different uses for Checkbox. This is a Good Thing, as it means that the tool is a useful one. However, in addressing their needs, each audience has forked the tool and created their own "flavor". This is a Bad Thing as it leads to code duplication, confusion, and an unmaintainably large set of packages.

Ideally we should try to meet all the use cases for Checkbox within the main branch of the tool. This will allow us to reduce confusion, add new features in a more consistent fashion, and generally make the world a better place for system testing.

Use Cases

Design

This design addresses the above use cases:

Implementation

A new configuration setting will be added to Checkbox containing the URL that points to a test definition file. This setting should be supported both in a configuration file (e.g. /etc/checkbox.d/checkbox.ini) as well as through a command-line option passed to Checkbox.

To satisfy this specification, only a single file containing test definitions need be accepted. Future functionality may be implemented by additional specifications.

UI Changes

No changes to the main UI will be necessary. A configuration file change and a new command-line option will be available.

Test/Demo Plan


CategorySpec

QATeam/Specs/CheckboxReduceFlavors (last edited 2010-05-27 19:51:29 by pool-98-110-168-38)