Looks OK to me. What is the advantage of split repos?

It might be helpful to split docs issues from tickets for review policy exceptions etc. Given that there's not that many tickets that are not docs-related, splitting the repos might not have a huge advantage though. It would just match what other teams have done too.

Ok. It feels like a single repo would be simpler for our purposes but if there are good reasons to split I'm not opposed. Just curious.

Also, the bikeshed should be painted mauve.

Probably not worth splitting, but I'm not strongly against it.

Yeh, I don't see that splitting will be a significant win and not doing it means we can just click the migrate button, which is nice.

But if you want to do it, then I'm not against it.

I think having separate repos makes context switching between issues and Guidelines PRs more difficult and doesn't provide any other benefit.

Any opinions on the organization name on forge?
https://forge.fedoraproject.org/forge/forge/issues/457#issuecomment-581262

My initial proposal was just "packaging-committee", as that matches what our repo here is called, Ryan asked whether using just "fpc" instead (matching "fesco") would be OK.

I like typing less, as long as there's no confusion with the "fpc" package.

I'd actually prefer "packaging" because then we can have guidelines, fedora-review, and other related things in one place

Note too there is also this open request -- https://forge.fedoraproject.org/forge/forge/issues/456

for packaging-tools

i'd lean towards combining these two TBH -- everything in a packaging organization, and then using additional forgejo teams to manage acls for specific repos or groups of repos.

Most other orgs just have an owners, and a members team, but we can have as many teams as you want all with access to different repos if you want.

A packaging org sounds good to me. This repo could be migrated over to packaging/commitee and continue to be both docs and FPC issues, or we could split it into packaging/commitee and packaging/guidelines. The EPEL Steering Committee did something similar. We migrated https://pagure.io/epel twice, first to epel/docs without issues, and then again to epel/steering with issues and proceeded to delete the content and disable the "code" unit in the settings. In either case I think we would want the group to be forge-packaging-committee, and then we'll give that group access to the repo(s).

A single packaging org sounds fine, but there should be a lightweight process for packagers to create/request additional repos and manage their permissions as stated in https://forge.fedoraproject.org/forge/forge/issues/456.

Thanks, can someone update the two tickets we have open for this, and consolidate the plan for how we want to approach the groups and teams for this?

https://forge.fedoraproject.org/forge/forge/issues/456
https://forge.fedoraproject.org/forge/forge/issues/457

Then i can implement it on the forge side for you all.

can someone update the two tickets we have open for this, and consolidate the plan for how we want to approach the groups and teams for this?

I'm not sure there is consensus here to add to the tickets. All I really want is to migrate fedrq and the Forge macros without endless bikeshedding. And there are other packaging tooling (such as fedpkg that is vital to the Fedora packaging workflow) that I don't maintain that also need a place. I first suggested having everything in a single packaging org when this was initially brought up on the packaging ML, but FPC members stated that they wanted the Packaging Guidelines (this repo) and maybe fedora-review in a separate org that was not used as a catch all for packaging tools which was why I requested a separate packager-tools organization. And now we're back at everything in one org.

As for the teams, I'm not sure how that should work here either. I asked for feedback from the Forge team when I filed the packager-tools org request about how to structure this. There should probably be a team for members of the FPC. For other packager tooling projects, using FAS groups would work but I question whether we need to create a group and team for every single repo when the Forge has functionality to manage users on a per-repo basis.

/me sighs and wishes not everything on forge.fp.o would need to be group-managed ...

/me sighs and wishes not everything on forge.fp.o would need to be group-managed ...

It doesnt. The ability to add collaborators to specific repos is still enabled.

Ideally, groups and teams is the cleaner way to do this, but in this case of the packaging tools, adding collaborators may be the way to go.

As before, happy to implement this, just need a firm decision on what to actaully do.

FYI -- also updated the packagingtools org request with an updated proposal:

https://forge.fedoraproject.org/forge/forge/issues/456#issuecomment-615913

Ok, if my original / simple permission structure is getting voted down, somebody else please suggest a new structure. I don't have capacity to work on this right now.

Okay, the conclusion in the meeting was please no more bikeshedding and that a single packaging org is preferred. I offered to handle the migration and figure out the details. I will put together a final proposal.

Here is my proposal. @ryanlerch, does this seem doable?

Primary requirements

This setup will unblock the FPC migration and the packaging tools requests.

• The forge-packaging-owners group should inherit from the packaging-committee FAS group and have admin permissions in the new packaging org.
• The forge-packaging-committee group should inherit from the packaging-committee FAS group and map to a committee team in the Forge org. This team will have admin on forge.fp.o/packaging/guidelines once I migrate this repository. I figured it'd make sense to have a separate committee team in case we need to change the owners team in the future (see open question 1 below for why we might want to do this).
• There should be a new forge-packaging-packager group that inherits from packager and maps to a packaging/packager team that has no special permissions in the org (readonly for everything) but can create repositories for packaging tooling.
• Org description: "This organization will host the Packaging Committee and other issue trackers, RPM macros, and generally useful tooling for Fedora packaging." I tried to make this pretty explicit and well-scoped but feedback is welcome.

Open questions

1. Will the admin team get automatically subscribed to all notifications for anything that happens in the org's repositories? I don't want to create a fire hose for all FPC members who would have admin perms in the org.
2. Once this repo is migrated, how do we change the Antora docs pipeline to point to the new repo?

Secondary requirements

• There should be a new forge-packaging-provenpackager group that inherits from provenpackager and maps to a packaging/provenpackager team in Forge. This team will have no special permissions in the org by default, but individual maintainers can choose to give this team ACLs on a per-repo basis if desired.
• Is it possible to create a packager-sponsors Forge team that inherits its members from the sponsors list of the packager group (and not the members list like the proposed packager team would)? This will be needed for https://pagure.io/packager-sponsors/ which we'll probably migrate to forge.fp.o/packaging/sponsors.
• Other packagers should be able to request teams by filing an Infra ticket if needed. For example, https://pagure.io/fedpkg/ and https://pagure.io/rpkg/ are maintained by the same people, so I imagine they might want their own team under the packaging org.

I updated the https://forge.fedoraproject.org/forge/forge org request tickets. Once the org and teams have been created, I'll migrate this repository and the issue tracker to https://forge.fedoraproject.org/packaging/guidelines.

Primary requirements

This setup will unblock the FPC migration and the packaging tools requests.

• The forge-packaging-owners group should inherit from the packaging-committee FAS group and have admin permissions in the new packaging org.

This group and team have now been created, and are linked via mapping (once the users log in to forge, if they are in the FAS group, they will be added to the Forge team)

• https://forge.fedoraproject.org/org/packaging/teams/owners
• https://accounts.fedoraproject.org/group/forge-packaging-owners/

• The forge-packaging-committee group should inherit from the packaging-committee FAS group and map to a committee team in the Forge org. This team will have admin on forge.fp.o/packaging/guidelines once I migrate this repository. I figured it'd make sense to have a separate committee team in case we need to change the owners team in the future (see open question 1 below for why we might want to do this).

This group and team have now been created, and are linked via mapping. (once the users log in to forge, if they are in the FAS group, they will be added to the Forge team)

• https://forge.fedoraproject.org/org/packaging/teams/committee
• https://accounts.fedoraproject.org/group/forge-packaging-committee/

I also set up the permissions for this one, so any repo that this team gets added to, they get Admin privs on -- org owners can change this in the team settings page.

• There should be a new forge-packaging-packager group that inherits from packager and maps to a packaging/packager team that has no special permissions in the org (readonly for everything) but can create repositories for packaging tooling.

This group and team have now been created, and are linked via mapping. (once the users log in to forge, if they are in the FAS group, they will be added to the Forge team)

• https://forge.fedoraproject.org/org/packaging/teams/packager
• https://accounts.fedoraproject.org/group/forge-packaging-packager/

I also set up the permissions for this one, so any repo that this team gets added to, they only get read access to, but they have the "create new repos" flag turned on.

• Org description: "This organization will host the Packaging Committee and other issue trackers, RPM macros, and generally useful tooling for Fedora packaging." I tried to make this pretty explicit and well-scoped but feedback is welcome.

Added this to the org description. However org owners can tweak at any time.

Open questions

1. Will the admin team get automatically subscribed to all notifications for anything that happens in the org's repositories? I don't want to create a fire hose for all FPC members who would have admin perms in the org.

Currently yes, but this default is turning out to be quite spammy for the way we have all our orgs set up in forge. So once i implement https://forge.fedoraproject.org/forge/forge/issues/529 later today, this should not be an issue anymore

1. Once this repo is migrated, how do we change the Antora docs pipeline to point to the new repo?

You will need to change where the docs site build precess looks, e.g.

• Staging -- https://gitlab.com/fedora/docs/docs-website/docs-fp-o/-/blob/stg/site.yml?ref_type=heads#L128
• Prod -- https://gitlab.com/fedora/docs/docs-website/docs-fp-o/-/blob/prod/site.yml?ref_type=heads#L128

Secondary requirements

• There should be a new forge-packaging-provenpackager group that inherits from provenpackager and maps to a packaging/provenpackager team in Forge. This team will have no special permissions in the org by default, but individual maintainers can choose to give this team ACLs on a per-repo basis if desired.

This group and team have now been created, and are linked via mapping. (once the users log in to forge, if they are in the FAS group, they will be added to the Forge team)

• https://forge.fedoraproject.org/org/packaging/teams/provenpackager
• https://accounts.fedoraproject.org/group/forge-packaging-provenpackager/

I also set up the permissions for this one, so any repo that this team gets added to, they get write access.

• Is it possible to create a packager-sponsors Forge team that inherits its members from the sponsors list of the packager group (and not the members list like the proposed packager team would)? This will be needed for https://pagure.io/packager-sponsors/ which we'll probably migrate to forge.fp.o/packaging/sponsors.

This is not possible on the Forge side -- the OIDC login process that we use to populate the teams does not give us sponsors. However, this is likely be possible on the IPA side with some creative group inheritance. Will have to get further information on how the sponsors list is updated -- this is worth a seperate infra ticket i think, and i can explain my solution there if needs be.

• Other packagers should be able to request teams by filing an Infra ticket if needed. For example, https://pagure.io/fedpkg/ and https://pagure.io/rpkg/ are maintained by the same people, so I imagine they might want their own team under the packaging org.

No worries -- just file a ticket here at forge/forge and we will get it done.