#5037 requesting new mailing list "fedora-atomic-bugs"
Closed: Fixed None Opened 8 years ago by miabbott.

= phenomenon =

There are a number of components under the Fedora product category in the Red Hat Bugzilla system with the QA Contact set to 'extras-qa@fedoraproject.org'. Based on discussions with folks in #fedora-admin, this list does not exist.

I would like to request a mailing list that can be used as the QA Contact for certain components that are specific to Project Atomic. For example, the components 'atomic', 'docker', 'ostree', and 'rpm-ostree'

There is currently a similar mailing list in place (used for the same reason) for the same
components under the Red Hat product.

= reason =

By creating the 'fedora-atomic-bugs' mailing list, it would allow users to receive notifications about bug activity specific to the Project Atomic components by subscribing to a single mailing list.

This seems preferable to having a user add themselves as a CC on multiple components. And the list of components may grow or shrink as time passes.

= recommendation =

I would recommend the creation of the 'fedora-atomic-bugs' mailing list.

Some IRC logs for references:

<miabbott> hi folks, i'm looking for information regarding the 'extras-qa@fedoraproject.org' mailing list.
<miabbott> it is used as qa contact on some components in the red hat bugzilla system, but it doesn't appear to exist on lists.fedoraproject.org
<nb> miabbott, /me suspects those components need to be updated
<nb> what kind of components? packages? or other things?
<miabbott> nb: packages under the Fedora product. for example: atomic, docker, ostree, rpm-ostree...
<miabbott> nb: i'm happy to get them changed, but i wanted to do my due diligence first
<nb> miabbott, /me looks
<nb> miabbott, looks like a lot of packages have that set, no idea
<nb> miabbott, maybe file a ticket on fedorahosted.org/fedora-infrastructure
<nb> asking what it should be set to
<miabbott> nb: thanks for looking. if i wanted to create a new fedoraproject.org mailing list that would be used as the qa contact, would i file a ticket in the same place?
<nirik> miabbott: it's an alias. It's currently unused.
<nirik> what are you trying to do?
<miabbott> nirik: i would like a mailing list that folks could subscribe to, in order to get bugzilla notifications for certain components
<miabbott> we do something similar for the previously mentioned components in the Red Hat product category
<nirik> well, we could setup a pkgdb group and have it cc'ed on bugs in the group going to a list
<nirik> Or each person could just add themselves to cc on those components and get the emails directly
<miabbott> nirik: i'd prefer the list approach
<nirik> ok, can you file a ticket with exactly what you want and we can try and get you setup.
<miabbott> nirik: thank you


So there are two ways to do this:

  • "fake" FAS user

So a "fake" FAS user would be an user the infrastructure set-up in FAS, without a password (we have this option) and that cannot do anything.
We would set the email of this user as the email of the mailing list and then you folks could just go to pkgdb and grant it watchbugzilla ACLs on any packages you like.

Eventually, we can also tell pkgdb to not check for this user if it is in the packager group which would give you the possibility to make this user the Point Of Contact of the packages, making it the default assignee of the bugs reported on bugzilla against this package.

  • pkgdb group

For this option, the Fedora Infrastructure creates a group in FAS. This group is invite-only, restricted to packagers and has for mailing list address the email of the mailing list you want to use.

The added value of this approach is that if you give commit access to this group in pkgdb, all the members of the group will be granted commit to the package automatically.
Similarly, you will be able to remove access to the entire group by removing the commit ACL to the group in pkgdb.
Granting/removing commit to someone for all the package is then done in a few clicks in FAS.

In both cases, the mailing list should be private as bugzilla will send information to it, including potential security bugs, and you will have to create the bugzilla account corresponding to the mailing list address.

So if you do not foresee the need to manage commit ACL, the fake FAS user could work, otherwise the pkgdb group should give you a little more flexibility if you ever wish to use this feature.

What do you prefer?

The pkgdb group seems most flexible? If there were a way to avoid private mail to the list, that'd be even better, as then the mailing list could be public and searchable. I guess that'd need an RFE for bugzilla though or something.

The mailing list could be public (we do not control the list, you'll be the admin) but that means security bugs might become public which most often isn't something you want.

So which solution do you prefer?

Let's go with the pkgdb group, thanks.

pkgdb groups must end with -sig, so I went with fedora-atomic-sig as group name :)

The group is created in FAS:

  • Do you want the fedora-atomic-sig mailing list as well or do you already have one? (To make private for security bugs in both cases)
  • You need to create the bugzilla account for the email you want associated with this group
  • You'll need to put the email corresponding to the bugzilla account as the Mailing list address for this group in FAS: https://admin.fedoraproject.org/accounts/group/view/fedora-atomic-sig

Once the mailing list is setup and configure, the FAS group is linked to the mailing list, you'll be able to grant ACLs to group::fedora-atomic-sig in pkgdb.

Note group::fedora-atomic-sig in pkgdb can have watchbugzilla, watchcommits, commits be the point of contact of a package but it can not have approveacls, so an actual user must have this ACL.

Has the mailing list been configured for this group?

The mailing list is now created and I added it in the group in fas.

So, I think everything is in place now.

Please let us know if there's anything further to do here or we can assist with.

Login to comment on this ticket.

Metadata