fesco

#3499 forge-packaging group in forgejo
Closed: Rejected by zbyszek. Opened by zbyszek.

Closed: Rejected
Reopen Issue

@ryanlerch proposed an forgejo "organization" (meta-team) in https://pagure.io/fedora-infrastructure/issue/12885#comment-992195. Proposal: approve this initial structure, with the general rule that a few representatives from each of the groups representing teams will be added to forge-packaging-owners to be able to add remove packagers into the respective teams. The general rule would be that people regularly working on some specific topic, e.g. reproducible builds, would be given write access to the appropriate repos whenever reasonable.

I don't really understand the request. What would be the benefit of moving mostly unrelated "Teams" under one overarching Organization? The way the request is phrased kind of sounds like anything that is not FESCo, Council, or Releng should be under Packaging.

In this structure, the forge-packaging-reproduciblebuilds team wouldn't have admin access to its own repositories which seems problematic. Also, it's unclear what actual groups of people forge-packaging-owners and forge-packaging-members correspond to. It was mentioned in https://discussion.fedoraproject.org/t/project-hosting-in-the-new-forge/162244/19 (and the following post) that all ~1500 packagers should not automatically have access to all repositories in the packaging organization.

In this structure, the forge-packaging-reproduciblebuilds team wouldn't have admin access to its own repositories which seems problematic.

A team can be given admin access to their list of repositories in Forgejo.

After discussion in the FESCo meeting, I'm withdrawing this request.

Metadata Update from @zbyszek:
- Issue close_status updated to: Rejected
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
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.