Rewrite

[cgwalters]

First, I personally have lost my appreciation for Python for years; the reasons are too long to elaborate but I would prefer Rust or golang for new code.

Second, I think the standard split between "CLI tool" and "service" (mock/koji) should be revisited in the age of containers. It's now a lot easier to spin up a set of services locally with oc cluster up (or use a remote service).

We don't want to entirely abandon CLI tools of course but I think they should be more co-developed.

Here's my strawman:

Keep the general idea of overlay.yml although we clearly need separate groups (today we have a lot of leaves)

Implementation/delivery is as container that runs in Kube/OpenShift, but we also support installing the CLI tools as RPM/whatever which run in a container.

resolve: Mirror git repos into a real git forge (gitlab? gogs? something else?)

build: For each group, fork of a build process that runs as a separate container - Kube Job. This generates an rpm-md repo.

Merge those repos at the end.

[cgwalters]

Or in addition/alternatively: Re-evaluate other things out there. There are a crap-ton of build systems. This one has some useful integration with RPM/dist-git land but we can probably at least pick up code/ideas from elsewhere too.

[Conan-Kudo]

You've got to be kidding me...?

Is there any good reason for rewriting this into an insane language (Go) or a difficult language (Rust)?

Putting aside that for the moment, there is no "age of containers" in the context of building packages. In nearly all modern build tools, we've always done it via some orchestration mechanism. Koji fulfills the same role as Kubernetes, it's just a hell of a lot more specialized.

Now, that being said, I think there's some value in making this better tooling for doing the merged-source model (a la ALT Linux and Debian). It would be interesting to see some specific integrations between this, Pagure/Kallithea, and Koji+Mock.

The value there is that people who do the fork+monkey-patch model for software delivery would appreciate a simpler workflow for doing that kind of stuff.

[cgwalters]

My current thoughts on this are that we should pursue a model where RPM builds are scheduled as Kubernetes jobs that just dnf builddep foo.src.rpm etc. That would be very straightforward and eliminate a lot of complexity.

For local developer builds then the story would be oc cluster up, etc.