Hi Andreas,
Andreas Enge <andr...@enge.fr> writes:
Hello Ian,
Am Sat, Feb 08, 2025 at 08:33:14AM -0800 schrieb Ian Eure:
- The QA status on issues.guix.gnu.org is not very useful. By
far the most
common thing to see here is "QA: Unknown," with no indication
of why it’s
unknown or when it may become known[1]. Sometimes this is
infrastructure
failures; other times, QA is overloaded. Both present the
same way. The
important information this should provide is, in large part,
absent. In
turn, that makes it much harder for contributors --
particularly
non-committers -- to ascertain if a given patch is problematic
or not.
my understanding is that moving to Codeberg would not
automatically
enable QA, but that we would still need to connect our own QA to
the
forge CI system. So this issue is essentially independent of
where we
host our sources - if any, the need for additional development
could
slow things down (but maybe the end result would be a simpler
system,
I do not know).
Yes, work would be needed to build the CI tooling. That could be
connecting the existing QA site to Codeberg, or building something
new. I’d advocate for the latter, since a pure CI job is lighter
weight than QA (it doesn’t need its own frontend), and as you
mention, hooking QA to Codeberg means the existing slowdowns of QA
would continue to happen.
The decision where to hose the sources matters in that Forgejo
provides explicit mechanisms for these kinds of things, which the
current tooling lacks. For example, you can prevent merges unless
the CI jobs pass, you can retry failing jobs, the jobs themselves
exist in the repo and can be managed by contributors in the same
way as the main code, etc.
- The depth of patch review is inconsistent depending on the
reviewer,
which I believe is due to lacking a consistent process for
doing so.
Forge-style CI would improve this: it could report whether a
package passes
`guix lint', whether it triggers a large number of rebuilds,
etc. The
consistent application of these standards will, I believe,
both ease burden
on committers (you don’t have to remember to check these
things) and raise
the consistency of these policies getting applied.
I think the main problem will remain the availability of
reviewers,
which again is independent of where the issues are hosted. But
indeed,
having a form where reviewers can check what they have done
might make
things easier.
Availability of reviewers will always be a bottleneck, but that’s
exactly why I believe improved tooling will help. Right now, a
proper review before committing is labor-intensive: you have to
pull master, apply the patch, run `guix lint', run `make', build
the package, etc etc. Automating this process both makes it more
accessible and lowers the burden of each review, which can[1]
increase overall throughput.
-- Ian
[1]: I specifially don’t say it /will/, but I do believe it /can/.
