Learn more about these different git repos.
Other Git URLs
While RPM repo creation is now automated (mostly), it seems response times for exceptions (iow replying valid to the bot) has actually slowed. Perhaps the mass rebuild has something to do with that, but it would be helpful if we could at least minimize the number of requests which require human intervention.
valid
The Flatpak SIG is just getting started, and there are going to be a lot more repo requests in the flatpaks namespace going forward. Right now, every single one is treated as an exception. To avoid that, could some criteria be used to auto-approve these, e.g. (in psuedocode):
(namespace MATCHES "flatpaks") AND (repo EXISTS in rpms namespace) AND ((maintainer IS-MEMBER-OF flatpak-sig) OR (maintainer IS-MEMBER-OF rpms/$repo))
Or perhaps it's enough just to be in packager group, not sure if that's too broad though.
the sooner this happens, the fewer valids you need to provide, but there will be a lot more requests coming soon.
N/A
more manual work for releng, and more frustration for flatpak contributors.
Metadata Update from @phsmoura: - Issue tagged with: medium-gain, medium-trouble, ops
Metadata Update from @humaton: - Issue untagged with: ops - Issue tagged with: dev
So, we discussed this some at this mornings releng meeting.
We aren't against the idea... but we aren't sure about 'flatpak-sig'. Since sig's normally have no rules for who is a sig member.
In this case I suppose we could make a group and the flatpak sig as a body could decide some rules for adding/removing people to that group so we could be assured that they were trustworthy fedora contributors and not someone just joining to add a bad flatpak. ;)
I went ahead and requested the flatpak-sig group: https://pagure.io/fedora-infrastructure/issue/11102
We are in a (kind of) similar situation with the Rust SIG, where we routinely need to create compat packages (which don't require package review). I'm not sure if automating this entirely is a good idea, but if somebody wanted a rule for it, then it would probably look something like this:
[0-9]
_0.1
_2
0.1
2
[0-9]+
0\.[0-9]+
0.9
0.12
0\.0\.[0-9]+
0.0.10
0.0.90
Edited step 1. to also take underscores into account
I floated this in IRC for Rust a while back, glad to see it's not just limited to Rust
I think Fabio's suggested algorithm for Rust would be safe. One caveat is it does not handle some weird corner cases e.g. where the base package ends in a number - rust-sha1 -- the compat package is actually rust-sha1_... e.g. rust-sha1_0.6. So in addition to step 1, if the next character is an underscore and after that you get a valid existing package ending in a digit that's valid too.
rust-sha1
rust-sha1_...
rust-sha1_0.6
Log in to comment on this ticket.