On Wed, Dec 15, 2021 at 05:46:18PM +0100, Miroslav Suchý wrote:
> Dne 14. 12. 21 v 17:12 Matthew Miller napsal(a):
> > > > But it seems like "request an EPEL branch" should generally be either 
> > > > "Okay!
> > > > Doing that automatically now" or "Oh, this is in EL, sorry"*. What are 
> > > > the
> > > > other cases?
> > > As far as I know this isn't about requesting EPEL branches, as much as
> > > requesting any branches by hand. If I add something to Fedora rawhide
> > > and then ask for a F34 branch, the same issues can happen. Remember
> > > our build infrastructure is a pile of band-aids on top of duct tape on
> > > top of bungee cords. Lots of tools are written for a toolchain which
> > > existed years ago and have been hacked to make it work with whatever
> > > new initiative that comes into play. 'Unexpected' side effects and
> > > corner cases happen all the time and the fixing of them tends to add
> > > new ones.
> > Sure. But also, asking people to spend a lot of their time running
> > grunt-work tasks means that they have less time to fix when things break,
> > let alone re-engineer away some of that tech debt. It seems like we should
> > be able to automate the simple cases (adding F34 and F35 branches should be
> > even easier, since we don't have the "is it in EL?" question even).
> 
> *nod*
> 
> So ... the question is how can I help? Can you document the check-list? I 
> volunteer to start writing the script.

So, I suspect the epel-devel list isn't really the place to discuss this
(I would think devel list + direct engagement with releng folks). 

That said, fedscm-admin _does_ do a bunch of checks currently. 

For branch requests for existing packages it checks that the requestor
is a maintainer of that package and then just auto approves it. Those
requests could potentially be automated (we have talked about it in
releng land, but it's also a bit difficult due to all the perms you have
to have). 

For new packages it does a bunch of checks like 'is the reviewer in the
packager group', did the reviewer set 'fedora-review: +', are the
requested branches valid, etc, etc
https://pagure.io/fedscm-admin/blob/main/f/fedscm_admin/utils.py#_285

I can't speak for the current folks doing the processing, but I did this
for 3-4 years a long time ago. When I did it I looked for a lot of
things it was hard to automate checks for, like "Did this review check
list a bunch of things, or just say 'ok, approved'". I would typically
look closely at those and find things that were missed. I also recall
several reviews that I blocked due to legal reasons where the reviewer
didn't understand things correctly. 

That said, the volume of new packages is pretty high these days so I
don't know how much extra scrutiny they are really getting. Perhaps it's
time to just completely automate it and have better ways to clean up if
something bad gets in. 

kevin

Attachment: signature.asc
Description: PGP signature

_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to