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
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.
Cheers, Nick.
----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: "beaker-devel" beaker-devel@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
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.
+1
Cheers, Nick.
-- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane
Test Automation Team Lead Beaker Development Lead (http://beaker-project.org/) PulpDist Development Lead (http://pulpdist.readthedocs.org) _______________________________________________ Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: "beaker-devel" beaker-devel@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.
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.
On 05/13/2013 04:33 PM, Dan Callaghan wrote:
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.
That makes sense. (And I guess I really should write that bug triage guide that has been on my todo list for a couple of months now...)
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
I quite like that. One concern I had with my suggestions was that the lines between categories are rather blurry, whereas package boundaries are nice and clear.
Since the documentation isn't packaged any more, we should keep that as a component, too.
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.
Fedora has a "distribution" catch-all for bugs which can't be neatly allocated to one package. We would probably need something similar for feature requests and the like.
Cheers, Nick.
beaker-devel@lists.fedorahosted.org