> I would like to streamline how Red Hat moves bugs back and forth between
> bugzilla and redmine. Currenty, we have a category of bugs grouped in
> "API" and "Hammer".
>
> I would like to try and break this categorization down a bit, into
> smaller functional chunks.
>
> I was thinking something akin to:
>
> API - Provisioning
> API - Host groups
> API - Users
We already have categories for unattended installation, host groups,
authn and authz, which bugs in any of those areas are usually assigned
to. The API category, like Web Interface is usually kept for issues
with the API itself.
I can only see four API tickets that are even tangentially related to
host groups, for example. Any tickets about host groups should be
assigned to "Host groups" instead.
> And have similar groups for Hammer:
>
> Hammer - Provisioning
> Hammer - Host groups
> Hammer - Users
Is that mapping to subcommands?
> This model uses a naming standard similar to Compute Resources. Another
> model would be to add a sub-category item so that API remains as is, but
> there is a way to sub-categorize.
Creating subcategories is fine, but I don't think there are many bugs at
all that match the ones you suggest. Making more specialised API or Web
Interface subcategories would be more useful than duplicating ones we
already have I think.
> Related to this question, currently foreman doe snot have a hammer
> component. Other plugins (Katello and Discover) do have hammer
> components. Is there a preference about the best way to do this? If we
> standardize, I can work with the project owners to get a consistent
> mapping between the two tools.
Normally a plugin just gets one project, as for small things like
Discovery I guess the admin overhead for maintaining them separately
would be overkill for the small number of tickets.
It's up to the project maintainers I guess, we can add them, but when
you've only got a few tickets and tightly integrated projects it's extra
work.
···
On 09/09/15 21:36, Bryan Kearney wrote:
–
Dominic Cleal
dominic@cleal.org
