fedora-infrastructure

#12970 New FAS group request: gcc-team
Closed: Fixed by kevin. Opened by siddhesh.

Closed: Fixed
Reopen Issue

Describe what you would like us to do:

I'd like to have a new FAS group for gcc package maintainers to allow distribution of gcc maintenance tasks in the team. This is primarily needed for some activities related to gcc maintenance that we have planned, including but not limited to:

  • maintaining snapshots of upstream trunk in a common copr namespace (gcc-team) for bisecting package build issues.
  • building snapshots of upstream trunk in a koji side tag to allow key packages to identify build failures early, allowing the team to adjust to the shorter mass rebuild window. I have made a releng request too for a branch and side tag that should be restricted to the team.

Initial members of this group should be:

  • @dmalcolm
  • @jakub
  • @mpolacek
  • @siddhesh
  • @vkadlcik

Ideally, I'd like @jakub and myself to be able to edit group memberships, adding and removing users as needed but that's not a hard requirement if the preference is to keep FAS membership management restricted to fedora-infrastructure.

When do you need this to be done by? (YYYY/MM/DD)

2025/12/15

Metadata Update from @zlopez:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: low-trouble, medium-gain, ops

Is this intended to be used to manage package permissions in distgit? If so, there are a couple extra requirements listed in https://docs.fedoraproject.org/en-US/infra/howtos/groups_in_fedora/:

  • It should end in -sig, not -team
  • It should have a private mailing list for Bugzilla.
  • Whether or not it's a distgit group, I the group is also supposed to have a short page under https://fedoraproject.org/wiki/Category:SIGs

@gotmax23 not for package permissions in distgit, although we would like to restrict build permissions for the side-tag we end up getting through releng ticket 13120 to this group allowing other packagers to only do scratch builds against that side tag. If there is still sufficient overlap that it's operationally easier to create this as a SIG then we could call it gcc-snapshot-sig.

A mailing list would be nice for packagers to reach out with questions or issues but we definitely don't want to track snapshot issues in bugzilla. These are transient unstable builds and are only there for packagers to keep track of upstream gcc changes.

I intend to write up a wiki page for this once I have the releng bits in place. If it has to be a SIG then I'll put it under Category:SIGs.

Thanks!

I does not need to be a packaging group if you don't intend to use it for that.

If you can confirm you don't need it to manage packaging perms I can make the group anytime here.

Yes, I don't need the group to manage packaging permissions. I primarily need it for a common copr namespace (gcc-team) to build snapshots into. e.g. instead of

https://copr.fedorainfracloud.org/coprs/siddhesh/gcc-snapshot-20251221/

I want us to be able to build

https://copr.fedorainfracloud.org/coprs/gcc-team/gcc-snapshot-20251221/

which multiple people can build into. Thanks!

Done.

You will need to logout and back on to copr to refresh the group membership.

Let us know if you run into any problems.

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

low-trouble medium-gain ops

None
None
Normal
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.