Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 235855 - auto-cc based on architecture
Summary: auto-cc based on architecture
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Bugzilla
Classification: Community
Component: Bugzilla General
Version: devel
Hardware: All
OS: Linux
low
medium vote
Target Milestone: 4.2-5
Assignee: Matt Tyson 🤬
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-10 15:10 UTC by Jeremy Katz
Modified: 2018-12-09 06:29 UTC (History)
3 users (show)

Fixed In Version: 4.2.4-6
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-15 03:53:42 UTC


Attachments (Terms of Use)

Description Jeremy Katz 2007-04-10 15:10:06 UTC
It would be nice to be able to have an auto-cc for a product based on the
architecture of the bug that was filed.  This would let, eg, the AlphaCore or
Aurora guys get automatically cc'd on any bugs filed for alpha or sparc.

Comment 1 Balint Cristian 2007-04-10 15:59:41 UTC
I would like in that case to subscribe for alpha arch, <cbalint@redhat.com>.

Comment 2 Noura El hawary 2008-12-15 06:45:29 UTC
basically there is auto cc of the bugs based on the components of the product. so for example if we add an email to the cclist of the devel component of the bugzilla product then this email will be auto cc'd an all bugs that gets filed against that component/product. To get added to the auto cclist of some component you will need to send an email to bugzilla-ownder@redhat.com with your request and cc your manager and the component owner with your request.

Noura

Comment 3 Jeremy Katz 2008-12-15 14:53:02 UTC
You're not following what the point here is. 

In Fedora, we have teams for the various secondary architectures (non-x86 arches).  These projects use Fedora bugzilla and *are* Fedora for all intents and purposes.  But since the hardware is not as common, it can be harder for the general pool of Fedora maintainers to fix architecture specific problems.

Rather than requiring reporters to add a cc to an architecture team list or requiring that package maintainers do so if an arch bug is reported, there has been the request for all bugs filed against the alpha architecture (or ia64 or sparc, etc) to automatically be cc'd to the appropriate team.  This is not something which is currently doable in bugzilla.  And just auto-cc'ing for all bugs in the product, then they will get everything and not just the architecture specific ones

Comment 5 Tom "spot" Callaway 2009-09-14 16:07:54 UTC
Commenting here, it would still be nice to get this feature implemented.

Comment 6 David Lawrence 2009-09-14 18:51:28 UTC
(In reply to comment #3)
> You're not following what the point here is. 
> 
> In Fedora, we have teams for the various secondary architectures (non-x86
> arches).  These projects use Fedora bugzilla and *are* Fedora for all intents
> and purposes.  But since the hardware is not as common, it can be harder for
> the general pool of Fedora maintainers to fix architecture specific problems.
> 
> Rather than requiring reporters to add a cc to an architecture team list or
> requiring that package maintainers do so if an arch bug is reported, there has
> been the request for all bugs filed against the alpha architecture (or ia64 or
> sparc, etc) to automatically be cc'd to the appropriate team.  This is not
> something which is currently doable in bugzilla.  And just auto-cc'ing for all
> bugs in the product, then they will get everything and not just the
> architecture specific ones  

I understand what is being requested and basically it is not currently supported in Bugzilla as it is not a trivial fix. We would need to create separate mapping table to keep rep_platform id and user ids mapped so when a new bug against a certain architecture is filed, it would add the appropriate cc members. This is best filed upstream if possible as someone who has time to work on it could grab it and it would be useful to others. We can try to get to it in time but we have
other projects we are working on currently.

One way to work around this using current BZ functionality is to create dummy Bugzilla accounts such as 

x86-maint@redhat.com
x86_64-maint@redhat.com
ppc-maint@redhat.com
...

And then either add those manually to specific bugs when needed (no code needed), or we could
potentially put a hack in to add them automatically when the bug is created (would need resourse allocated).
Then users who want to get notified when bugs get changed that have one or more of these dummy users cc'ed, they can simply set their account to watch the relevant users in their email preferences.

Dave

Comment 9 Simon Green 2012-06-19 03:26:12 UTC
This is doable, via an extension. Do you want to be CC:ed on all bugs if the particular architecture is selected, or only for selected products?

dkl is correct that this would need to be specified in a separate config, but we are doing this for other things anyway.

  -- simon

Comment 10 Tom "spot" Callaway 2012-06-21 18:42:34 UTC
I suspect we'd only want this to be for selected products. For example, I bet IBM probably cares about PPC64 for both RHEL and Fedora, whereas, I only want this sort of thing for SPARC* on Fedora.

Comment 11 Simon Green 2012-06-22 03:30:11 UTC
Speak up if any of these two things present a problem to you.

If say xyz@acme.com (a non privileged user) is on the auto-cc list, and the bug is private, we won't add the user to the CC: list. This mirrors they way component CC lists are handled, where a non privileged user is not added as a CC: to a bug they otherwise wouldn't be able to see the bug.

If the product, component or arch is changed, new people may be added to the CC: list, but existing people won't be removed. The existing users may of course manually remove themselves.

  -- simon

Comment 12 Tom "spot" Callaway 2012-06-22 11:37:50 UTC
Neither of those present a problem to me. We don't really have private bugs in Fedora, and the behavior you describe with CC handling is consistent with how CC handling is done in other areas already,

Comment 15 Simon Green 2012-09-12 03:53:33 UTC
Can people that want to receive notifications based on architecture, please list on this bug what arch(s) and product(s) they want to receive notifications on in the next fortnight.

  -- simon

Comment 16 Tom "spot" Callaway 2012-09-12 12:53:08 UTC
For me:

Fedora * : sparc*

(Although, I suspect you'll want some other mechanism of enabling this, because I know IBM folks will probably want to be able to enable PPC* watches on themselves later, and I doubt they're tracking this 5 year old bug. :) )

Comment 19 qiyun 2012-09-24 07:03:00 UTC
It is verified on bzweb01-qe(build version 4.2.3-5.b01).

Verify steps:
1.Add auto-cc ruels in /etc/rh-bugzilla/config.yaml like this:


auto_cc_rules: 

  - email: [ 'yqi@redhat.com', 'yuwang@redhat.com' ]

    product : [ 'yqi-test1', 'yqi-test2' ]

    platform : [ x86_64 ]

  - email: [ 'jihu@redhat.com', 'xma@redhat.com' ]

    product : [ 'yqi-test3' ]

    platform : [ i686, i386 ]

2.Create bug for product yqi-test3 and platfor i386,filled in other nessary infos and submit it.

Actual resutls:

1.On the left top of submitted bug page,there are message like this:


Bug 842477 has been added to the database

    Email sent to:
        jihu@redhat.com, jzhao@redhat.com, jingwang@redhat.com, xma@redhat.com 
    Excluding:
        dli@redhat.com 

Note:
1.jzhao@ is the reporter and this bug is assinged to jingwang@.

2.For the scenarios that the bug only match the product or platform,the users in config.yaml will not be listed in auto-cc list.

3.For private bugs,the private user will be listed in auto-cc also.
But the users are not included in the private group even though they are added in config.yaml,will not be listed in auto-cc list.


Note You need to log in before you can comment on or make changes to this bug.