Currently the requests are processed using https://pagure.io/fedscm-admin/tree/master.

Special case is needed for epel branches.

16:27 <pingou> cverna: I think for epel we should try to mimic pkgdb's behaviour
16:28 <pingou> ping the current maintainer and give them a week to +1/-1 the ticket
16:28 <pingou> if they don't respond or say +1: approve
16:28 <pingou> if they -1: deny
16:28 <pingou> which implies, reacting to comments as well as running daily

Current behavior is that only a package admin can request an epel branch.

Started to discuss a automation framework for releng tasks in https://lists.fedoraproject.org/archives/list/rel-eng@lists.fedoraproject.org/thread/6AQ75AV2SIYWJYHAJQSYYBZ7RN4J5T5C/

Here's my idea:

add 2 plugins to pagure-dist-git:
1. A 'request branch' button that lets someone request a branch to a existing package. It checks that they are a maintainer/admin and then just does it. or sends a message and a toddler just does it.

1. A 'request new package' page that lets someone fill in info to request a package, it runs checks and just does it, or emits a message or sends a message and a toddler does it.

or

keep the existing tickets system, but have a toddler that processes them instead of a human.

As discussed in the morning stand-up today, I brought up the possibility that $dayjob will assign me an intern this summer that I can volunteer for this. Not guaranteed though.

Meanwhile, @kevin suggested bringing in @pingou to get some feedback on the two possible approaches (keep ticket-based, or scrap it) so we can start scoping this out. I'll catch up on the mailing list thread from 2 years ago then maybe start a new one for this.

We started to work on this ticket together with @siddharthvipul1.

For start we created a document and tried to look at the possible solutions mentioned by @kevin more closely.

Feel free to comment on the document, so we can see which solution will be more feasible.

please ignore my emoji reaction spree in the last comment
I was trying to see how to remove the reaction -- and ended up putting all of them (it's been a long day)

There is a work in progress PR opened on toddlers.

The PR is merged, but before deployment to production I first want to test this on staging. I already created a ticket to request staging environment for toddlers. I will prepare the ansible script for staging environment and test toddler on the staging SCM requests. If the tests will be OK, I will continue with deployment in production.

Staging environment for toddlers is now deployed and running, but there is issue with pagure not emitting messages on staging, which blocks the testing in staging.

I'm looking into this.

I was able to finally process all the tickets on staging scm-requests repository.
I will try to create a ticket on staging that should pass, but I would like a help from releng on this.

I was able to test creating repositories and branches, even the manual validation works on staging. I will try to do some stress test by creating multiple request at once. But otherwise it seems that the scm_request_processor is getting ready for the production.

This will be deployed in production on January, announcement was already sent.

The automation is now deployed in production and all the tickets are processed by it. There were few hiccups, but they are now solved.

Closing this ticket as fixed.