releng/tickets

Fork 2

Automation of request-repos in flatpaks namespace #11233

New issue

Open

opened 2023-01-23 18:25:33 +00:00 by yselkowitz · 7 comments

yselkowitz commented

2023-01-23 18:25:33 +00:00

Member

Describe the issue

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.

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.

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

the sooner this happens, the fewer valids you need to provide, but there will be a lot more requests coming soon.

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

N/A

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

more manual work for releng, and more frustration for flatpak contributors.

* Describe the issue 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. 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. * When do you need this? (YYYY/MM/DD) the sooner this happens, the fewer `valid`s you need to provide, but there will be a lot more requests coming soon. * When is this no longer needed or useful? (YYYY/MM/DD) N/A * If we cannot complete your request, what is the impact? more manual work for releng, and more frustration for flatpak contributors.

phsmoura commented

2023-01-23 19:12:33 +00:00

Metadata Update from @phsmoura:

Issue tagged with: medium-gain, medium-trouble, ops

**Metadata Update from @phsmoura**: - Issue tagged with: medium-gain, medium-trouble, ops

humaton commented

2023-01-24 09:36:41 +00:00

Owner

Metadata Update from @humaton:

Issue untagged with: ops
Issue tagged with: dev

**Metadata Update from @humaton**: - Issue **un**tagged with: ops - Issue tagged with: dev

kevin commented

2023-01-24 18:10:24 +00:00

Owner

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. ;)

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. ;)

kalev commented

2023-01-25 12:46:58 +00:00

Contributor

I went ahead and requested the flatpak-sig group: https://pagure.io/fedora-infrastructure/issue/11102

decathorpe commented

2023-01-28 20:21:05 +00:00

Contributor

strip [0-9], dots (optionally, with one leading underscore) from the right side of the package name in the request (i.e. _0.1, _2, 0.1 or 2)
if rpms/package-name-without-suffix already exists, then request is OK. if that doesn't exist, then not OK, as there is no package with the unversioned "base name"
check if stripped digits and dots from step 1 match any of these patterns: [0-9]+ (i.e. a number without dots), 0\.[0-9]+ (a version like 0.9 or 0.12), or 0\.0\.[0-9]+ (a version like 0.0.10 or 0.0.90). These are the only valid "compat suffix" patterns for Rust packages, if the suffix looks like something else, then it's either packager mistake or an invalid request.

Edited step 1. to also take underscores into account

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: 1. strip `[0-9]`, dots (optionally, with one leading underscore) from the right side of the package name in the request (i.e. `_0.1`, `_2`, `0.1` or `2`) 2. if rpms/package-name-without-suffix already exists, then request is OK. if that doesn't exist, then not OK, as there is no package with the unversioned "base name" 3. check if stripped digits and dots from step 1 match any of these patterns: `[0-9]+` (i.e. a number without dots), `0\.[0-9]+` (a version like `0.9` or `0.12`), or `0\.0\.[0-9]+` (a version like `0.0.10` or `0.0.90`). These are the only valid "compat suffix" patterns for Rust packages, if the suffix looks like something else, then it's either packager mistake or an invalid request. --- Edited step 1. to also take underscores into account

salimma commented

2023-02-09 17:16:29 +00:00

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.

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.