#9927 Add commit privilege for https://pagure.io/fedora-comps/ to proven packagers
Opened 2 years ago by zbyszek. Modified 2 months ago

A few years ago comps were writable by any packager. With a move to pagure, the list of people who can make changes was severely curtailed, currently just a few people + releng. This was done without any discussion, implicitly as part of the move.

As with other similar setups, this creates a choke point whenever @releng is swamped with other things. Pull requests to comps are not being reviewed and merged in time (https://pagure.io/fedora-comps/pull-request/509, https://pagure.io/fedora-comps/pull-request/543, https://pagure.io/fedora-comps/pull-request/567, others).

I'm sure plenty of people would like to help with this, but are blocked by the centralization of write privileges. I think allowing all proven packagers to write to the repo would help resolve the issue. There is really no need to restrict this to @releng, since @releng doesn't really know too much about KDE spin or i3 desktop. Groups should be managed by people who work on those groups. Restricting this to proven packagers is a reasonable compromise IMHO.

  • When do you need this? (YYYY/MM/DD)

Weeks rather than months.

  • When is this no longer needed or useful? (YYYY/MM/DD)

Never.

  • If we cannot complete your request, what is the impact?

See description.


The provenpackager and packager groups do not exist on pagure.io. That said, virtually all major SIGs have corresponding pagure.io groups, so we could request to grant those write permissions.

At least offhand, all working groups and the KDE SIG have membership managed through Pagure groups on pagure.io.

+1 to the idea. If this is technically not possible, we could make a "comps sig" group and populate it with any provenpackager and/or package group maintainer who expresses interest.

I'm gonna dispute your premise...

As with other similar setups, this creates a choke point whenever @releng is swamped with other things. Pull requests to comps are not being reviewed and merged in time (https://pagure.io/fedora-comps/pull-request/509, https://pagure.io/fedora-comps/pull-request/543, https://pagure.io/fedora-comps/pull-request/567, others).

509 -> as you asked in comments, the status is unknown. Really to merge this we need input from the kde sig... and the pull request isn't something they are pushing, just something someone else decided to do.

543 -> was just missed, a ping anytime would have gotten someone to merge it. It's merged now.

567 -> filed the day after xmas... I didn't expect anyone to see it until after holidays, but it's simple enough, so I just merged it.

Everything else is still under discussion/deveopment...

I don't think the problem is lack of people to merge things, I think it's more a lack of subject matter experts/sigs/working groups providing timely review.

Or perhaps it's that we don't close PR's very well. IMHO 509 and 488 could be dropped with "please figure it out in kde land and resubmit when everyone is happy with it"

Anyhow, I have no objection to adding more people to merge things, but I don't think thats the problem.

was just missed, a ping anytime would have gotten someone to merge it
filed the day after xmas... I

Yeah, but I don't want to ping you (or other releng members) during the holidays. That's essentially the whole point: I (and I assume others) want to help, without interrupting your well-deserved time off, but we're blocked by overly restrictive policy.

Anyhow, I have no objection to adding more people to merge things

Cool.

We need to look at how to sync fas groups into pagure.io, pinging @pingou for more insight.

Metadata Update from @mohanboddu:
- Issue tagged with: high-trouble, medium-gain, ops

2 years ago

From the releng meeting today

[11:14:12] <mboddu> #info pingou is going to look at how we can sync the fas groups into pagure.io

Metadata Update from @mohanboddu:
- Issue untagged with: high-trouble, ops
- Issue tagged with: dev, medium-trouble

2 years ago

This would be useful to package-maintainer-docs as well,
that repo it a good candidate to be managed by the fas packager group.

I wonder... could we make a fedora-comps rpm package (thats just comps files) on src.fedoraproject.org and then point pungi/etc to use that instead of the pagure.io one?

Then it would still be open for pr's and it would also be open to provenpackagers to make changes?

But then we have the overhead of making the rpm from time to time...

could we make a fedora-comps rpm package (thats just comps files) on src.fedoraproject.org

If people find this idea acceptable, I'd be happy to provide a spec file and take it through review.

But then we have the overhead of making the rpm from time to time...

Would we want to actually ever build the package? We could just have it in dist-git and point pungi/etc directly to the dist-git repo. This would solve the access issues without changing the workflow.

One possible monkey wrench in this plan: translations. We have weblate pushing to the pagure repo. I am not sure it can do that to src.fedoraproject.org.

It'd need to be pointed at a different address, but in principle it could work. You can submit pull requests on src.fp.o without a packager account.

Login to comment on this ticket.

Metadata
Boards 1
Dev Status: Backlog