#7628 bugzilla - change default assignee for cockpit
Closed: Fixed 4 years ago by martinpitt. Opened 5 years ago by martinpitt.

  • Describe what you need us to do:

The Fedora "cockpit" package in bugzilla still has a default assignee pvolpe@redhat.com. Peter has left the company over a year ago. As Red Hat Cockpit team lead and main Fedora/RHEL packager I (mpitt@redhat.com) would like to become the default assignee.

  • When do you need this? (YYYY/MM/DD)

No specific deadline.

  • When is this no longer needed or useful? (YYYY/MM/DD)

N/A

  • If we cannot complete your request, what is the impact?

Missing notifications for new Fedora bug reports

CC @dperpeet FYI


So, this is supposed to be set by a script that syncs from src.fedoraproject.org pagure. The 'main admin' there should be the one who is default assignee for the package, and all admins and watchers get cc'ed.

For some reason however, that doesn't seem to be happening here. This might be a pagure bug or... can you go to https://src.fedoraproject.org/rpms/cockpit and make sure you didn't select 'unwatch' for some reason?

@pingou any insight?

https://src.fedoraproject.org/extras/pagure_poc.json shows martinpitt has POC (for the rpm package, the maxamillion is POC for the container)

The CC list should be:

        "cockpit": [
            "pvolpe", 
            "martinpitt", 
            "dperpeet", 
            "cockpit", 
            "stefw", 
            "ichavero"
        ], 

Metadata Update from @bowlofeggs:
- Issue priority set to: Waiting on Assignee (was: Needs Review)

5 years ago

Yeah, I think the cc list is ok, it's the main assignee thats wrong. There's not an override... and it's wrong in extras/pagure_bz.json too, so I think pagure is generating it wrong somehow...

pagure_bz.json is the one generating:

        "cockpit": [
            "pvolpe", 
            "martinpitt", 
            "dperpeet", 
            "cockpit", 
            "stefw", 
            "ichavero"
        ], 

Which is the CC list, pagure_poc.json is the one generating the Point of Contact (ie: default assignee) and it points to martinpitt

Could the script simply be crashing or have trouble running?

ok. yes, the script was crashing on the modularity-wg group having commit on modules/cloud-init and modules/389-ds. The modularity-wg is of type 'tracking' not 'pkgdb', so I think that was what was confusing it, or perhaps because there's 75 users in the group and perhaps some of them don't have bugzilla accounts? I removed the group for now from those two projects until we can sort how to fix it.

Even doing that however, the script now completes, but changes don't seem to happen. I can see:

Assesssing bugzilla status for u'cockpit'
[EDITCOMP] Changing via editComponent({'product': 'Fedora', 'initialcclist': [u'pvolpe@redhat.com', u'mpitt@redhat.com', u'dperpeet@redhat.com', u'cockpituous@gmail.com', u'stefw@redhat.com', u'ichavero@redhat.com'], 'component': u'cockpit', 'initialowner': u'mpitt@redhat.com', 'description': u'Web Console for Linux servers'}, fedora-admin-xmlrpc@redhat.com, "xxxxx")

but nothing changes. I logged in manually using our fedora-admin-xmlrpc account and was able to change the owner from the web interface, so that works.

So, bugzilla is accepting our changes, but silently dropping them?

FYI, I manually changed cockpit via the web interface, so the thing that was asked in this ticket is done.

Still we should fix the script working before we close this.

This would work if the cockpit user had a bugzilla account associated with its email, so I have just emailed the cockpit team (hi @martinpitt, you have an email :)) asking them if they could create one.

Once this is fixed, I think we can consider this ticket fixed :)

@pingou, where did you send it to? I don't see it. https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahosted.org/ ?

But I don't understand what this has to do with a "cockpit" user in the bugzilla context? I'd like myself (mpitt AT rh) to be the default assignee.

Thanks!

I sent it to the email address set in FAS for the cockpit user cockpituous@...

But I don't understand what this has to do with a "cockpit" user in the bugzilla context? I'd like myself (mpitt AT rh) to be the default assignee.

We do a single request when updating information about a package (so as to reduce the load on bz), so we update the default assignee, the CC list and a few other items in one request.
If that request fails, none of the changes go through.
In the case of rpms/cockpit the cockpit user is included in the CC list and has an email address cockpituous@... which is not found in bugzilla.
So bugzilla fails the entire request and thus does not make you the default assignee.

Does that make sense?

@pingou: It does, thanks! I'm afraid I don't have access to the cockpituous gmail account. However, it seems to me that the simplest and most robust way to fix this is to simply drop cockpituous from the default CC list -- there's no point in that bot account receiving bug mail. Can I do this somewhere, or is that something that you bz admins do?

FTR, the recent two bugs against Fedora Cockpit (https://bugzilla.redhat.com/show_bug.cgi?id=1791150 and https://bugzilla.redhat.com/show_bug.cgi?id=1791150) were correctly default-assigned to me, so the original issue of this ticket is fixed. Many thanks!

I'm surprised bugzilla got updated considering I'm still seeing the failure due to the cockpit user.

If you can log into src.fp.o as the cockpit user, you can then "unwatch" all the projects "cockpit" has commit access for and that will drop it from the CC list (you can see the effect are, for example: https://src.fedoraproject.org/api/0/rpms/cockpit/watchers ).

Sorry for the late reply, this slipped through the cracks -- I made the cockpit user unwatch all projects, https://src.fedoraproject.org/api/0/rpms/cockpit/watchers is clean now.

Can we close this one now?

Yes, I suppose. Thanks for your help!

Metadata Update from @martinpitt:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Metadata
Attachments 1
Attached 5 years ago View Comment