Is this the go-sig?

You need the group to be admin on all the packages you want commit activity and bug activity for.

It looks like from the archives this is happening? Can you expand on whats not working for you?

On Wed, 31 Oct 2018, 21:11 Kevin Fenzi <pagure@pagure.io wrote:

kevin added a new comment to an issue you are following:
``
Is this the go-sig?

You need the group to be admin on all the packages you want commit
activity and bug activity for.

It looks like from the archives this is happening? Can you expand on whats
not working for you?
``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-infrastructure/issue/7329

It works now because I made a dummy Fas account with the go-sig mailing
list as mail to use with fedmsg. Not sure if this was the correct way to
proceed. Despite being coadmin on the packages, I didn't receive the mails
before.

You should not have to do that at all.

@pingou can you see what might be wrong here? The go-sig is setup in fas with the list address as it's list-address.

From the discussion here, I suspect it's something with FMN since dist-git doesn't send notifications.

Well, lets look at the bugzilla case.

go-sig@lists.fedoraproject.org is a valid bugzilla user.
the go-sig group has 'commit' on rpms/etcd
however, watchers ( https://src.fedoraproject.org/api/0/rpms/etcd/watchers ) show it only following 'issues'
bugzilla shows it's not connected to any packages: Product responsibilities: none

So, perhaps the pagure sync to bugzilla isn't populating that right?

On the commits side, I am not sure how it is supposed to work... FMN only knows about users right?

We really need to actually document all this, I get confused everytime, and it often has issues somewhere and it's a pain to find out where.

Any help with this?

This and Anitya not sending the bugs anymore makes it really hard to keep track of hundreds of packages.

On the commits side, I am not sure how it is supposed to work... FMN only knows about users right?

It knows about groups, it queries pagure to know all the maintainers of a package (users and groups) then for each group, it queries FAS to get the member list.
(source: https://github.com/fedora-infra/fmn/blob/abfc610bd443df2ae588f3d5ce4e1c689cd59c71/fmn/rules/utils.py#L144 )

huh, so thats good and fine, but we ALSO need it to use the mailing-list field for the group and mail there. How did it work with pkgdb? has it been broken since then?

For pkgdb, it seems FMN worked in the same way: https://github.com/fedora-infra/fmn/blob/abfc610bd443df2ae588f3d5ce4e1c689cd59c71/fmn/rules/utils.py#L222-L231

Looking at the database, it seems we created a rule(s) for the desired SIGs with a pseudo user to send the commit notifications to their list.

Few queries to run against the notifications database to see what I mean:

select * from detail_values where value like '%lists%';
-- in the queries below, see the 'openid' field
select * from preferences where id = 3578;
select * from preferences where id = 6064;
select * from preferences where id = 9585;

I guess we did this to avoid having one person setting this up for the SIG and then going away and access getting lost.

Ok looking at the bugzilla angle, it seems the json files containing the data to propagate to bugzilla was just a) entirely ignoring groups and b) by-passing contributors: https://pagure.io/pagure-dist-git/pull-request/64 should fix that (I can put the hotfix in ansible if we need this sooner)

Is this fixed now?

No change here.

pagure-dist-git 1.1 has been released with this fix and deployed in staging :)

@kevin, should we schedule some time to push this to prod, maybe sometime next week?

Please do. I thought it was already pushed. ;(

Anytime you have time I guess....

This has been pushed to production today as part of the 1.2.1 release.

Let's see if the next sync sets thing up correctly

@eclipseo Did you see any change on your side?

This looks to be fixed to me.

Please re-open if you still see any issues, or file a new ticket.

:signal_strength: