----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: "beaker-devel" <beaker-devel(a)lists.fedorahosted.org>
Sent: Monday, May 13, 2013 1:44:24 PM
Subject: [Beaker-devel] Defining a more useful component list in Bugzilla
The current component list in Bugzilla has a few limitations, with some
bugs being thrown at a component more or less at random, since they
don't fit any of the existing components. In other cases, the component
is too broad, failing to make appropriate distinctions in the assignments.
Here's the current component list:
command line
Doc
inventory
qpid
lab controller
scheduler
reports
tests
test harness
web UI
Those actually aren't *that* bad, there are just some missing ones and a
couple could do with a name change.
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
+1.
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)
+ 1 to the above.
server XML-RPC (for central issues that aren't related to
the web
UI or scheduler)
I am trying to understand exactly which bugs we classify into this category. The major
user of the XML-RPC interface AFAIU is
the 'bkr' cli itself. So, are you suggesting that we confine the I part of the CLI
to 'bkr cli' and anything to do with the interfacing
with the server via XML-RPC go into this new category?
multiple (problem/feature that spans multiple components)
+ 1. And perhaps a comment suggesting the components it could span.
unknown (for bugs that haven't been triaged yet)
+ 1
Fedora compatibility
+1 to Fedora compatibility.
I'm *not* sure those proposals actually make sense, but I wanted to
provide a starting point for discussion.
Does it make sense to limit the scope of "scheduler" component to only bugs
which involve
actually scheduling? (for example, a broken machine is chosen to be scheduled) and have a
separate category "server" for bugs such as "a group feature is
broken" ? (I think, right now, we
would classify this bug in the scheduler category).
-Amit.
--
Amit Saha <
http://echorand.me>
Infrastructure Engineering and Development
Red Hat, Inc.