Excerpts from Nick Coghlan's message of 2013-05-13 13:44:24 +1000:
Suggested name/scope changes:
qpid -> notifications (covering both AMQP sending and receiving and
email sending)
tests -> test suite
inventory -> inventory task
test harness -> beah test harness
command line -> bkr CLI
Suggested new components:
beaker-wizard CLI
other tasks (covers all standard tasks other than the inventory task)
harness API (for the new stable harness API)
server XML-RPC (for central issues that aren't related to the web
UI or scheduler)
multiple (problem/feature that spans multiple components)
unknown (for bugs that haven't been triaged yet)
Fedora compatibility
I'm *not* sure those proposals actually make sense, but I wanted to
provide a starting point for discussion.
These sound more like bug "topics" or "feature areas" than actual
components. I think it makes more sense to continue using a whiteboard
field for that, since redefining them is not a big deal and we can
easily add new ones -- unlike component.
There was some talk in the past that our internal release tooling would
require us to use package names (or subpackage names) as our Bugzilla
components. I'm not sure if that's accurate but it might be a reasonable
way to split the components anyway.
beaker-server
beaker-lab-controller
beaker-client
beaker-integration-tests
beah
rhts
plus I guess an extra one for the tasks we maintain. It has the added
advantage of making it clear which package needs to be updated for the
fix. The downside is there is no way to handle fixes which cross
multiple subpackages, which is probably quite a lot of them.
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.