We've previously discussed revamping the Beaker component list in Bugzilla, but never come up with anything that seemed worth the hassle.
However, looking at it from the perspective of "handling bugs that don't currently have a good home", I think two new components would cover us.
1. "server"
This component would be used for all server-only bugs that aren't specific to the web UI, the scheduler, native reports. Bugs for kickstart generation, permissions issues, data model cleanups, server-only utility scripts would all live here.
2. "core tasks"
This would cover any bugs related to the standard tasks that don't have a dedicated component (i.e. anything that now lives in beaker-core-tasks, other than the inventory task). The "inventory" component would cover both the inventory task and beaker-system-scan.
So the overall structure would be:
general Doc server scheduler web UI reports lab controller qpid (since distro expiry is our only current messaging support) command line test harness (beah and beah-ipv6) core tasks (beaker-core-tasks) inventory (includes beaker-system-scan) tests (includes beaker-meta-tasks)
Thoughts?
Cheers, Nick.
Excerpts from Nick Coghlan's message of 2013-11-25 12:11:14 +1000:
We've previously discussed revamping the Beaker component list in Bugzilla, but never come up with anything that seemed worth the hassle.
However, looking at it from the perspective of "handling bugs that don't currently have a good home", I think two new components would cover us.
- "server"
This component would be used for all server-only bugs that aren't specific to the web UI, the scheduler, native reports. Bugs for kickstart generation, permissions issues, data model cleanups, server-only utility scripts would all live here.
- "core tasks"
This would cover any bugs related to the standard tasks that don't have a dedicated component (i.e. anything that now lives in beaker-core-tasks, other than the inventory task). The "inventory" component would cover both the inventory task and beaker-system-scan.
So the overall structure would be:
general Doc server scheduler web UI reports lab controller qpid (since distro expiry is our only current messaging support) command line test harness (beah and beah-ipv6) core tasks (beaker-core-tasks) inventory (includes beaker-system-scan) tests (includes beaker-meta-tasks)
Thoughts?
My thoughts are the same as last time :-) which is that the *only* purpose those components serve is to tell us "has this fix been released yet?" or perhaps "what do I need to update to get this fix?" The simplest way to do that is to just use the package name as the component.
On 11/25/2013 12:42 PM, Dan Callaghan wrote:
My thoughts are the same as last time :-) which is that the *only* purpose those components serve is to tell us "has this fix been released yet?" or perhaps "what do I need to update to get this fix?" The simplest way to do that is to just use the package name as the component.
With "general" as a catch-all for needing to update multiple things.
Fair point - Ray's current review of all the release artifacts may help with that :)
Cheers, Nick.
beaker-devel@lists.fedorahosted.org