Learn more about these different git repos.
Other Git URLs
There supposedly happened mass rebuild of Fodura modules. But unfortunately, it was not worth of the effort IMO, because the only result of the mass rebuild of modules for Ruby was this build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1461804
This is IMO failure, because obviously master is quite meaningless branch in modularity (or at least in Ruby case). But obviously, the question is what to actually rebuild, if not master. And that is the problem. Modularity is so vague about branching model, that it is not possible to understand what branch is actually used and useful. It would be nice, if default branching recommendations are provided.
Also, https://pagure.io/modularity/issue/142 is related, because it really is necessary to avoid the explicit ref:, otherwise it is not possible to work with the branches effectively.
ref:
Branching modules in reality means building streams existing in Rawhide before branching for the new Rawhide's platform after branching. E.g. when branching Fedora 36 from Rawhide, it means building modules which existed (or are supposed to exist) in Fedora 36 (i.e. run-require platform:f36) again for Fedora 37 (i.e. to run-require platform:f37).
It's rather a mass-rebuild than creating new dist-git branches. That's because module streams have dist-git branches independent from Fedora releases. It's because a platform stream for Fedora Rawhide is not a floating "rawhide" alias, but it's a release number ("f36").
For the very same reason letting component ref values follow the platform (#142) would not work: There is no f37 dist-git branch (at the time of Rawhide being Fedora 37). There are branches "rawhide" and and alias "main".
Currently we have two input module formats for building modules (i.e. what goes from dist-git to MBS): modulemd-v2 and modulemd-packager-v3:
modulemd-v2, if stream expansion is applied (e.g. "buildrequires: platform:[]"), requires only submitting the module for building. No changes in the YAML file, no empty commit is needed. MBS will perform the expansion, discover a new platform stream, and spawns a new sibling build coupling the previous module build.
modulemd-packager-v3 does not apply stream expansion and needs adding a new "configurations" subblock for the new platform. The changes needs to be pushed and built. Result will be builds for the previous platforms and the new one. Builds for the previous platform will usually reuse RPM packages from the previous module builds; the a build for the new platform will build everything from scratch. Adding the new configurations subblock can be automated with a new tool under development https://github.com/rpm-software-management/modulemd-tools/pull/52.
AFAIK nowadays relengs on branching import a new platform stream into MBS (e.g. platform:f37) and then attempt to rebuild the modules (modulemd-v2 case). I will work with them to cover the modulemd-packager-v3 case in the future. I believe that they do not rebuild "master" streams anymore. They only rebuild streams existing the previous "modular-rawhide" repository.
Once I get in touch with relengs, I will link theit branching standard operation procedure pertaining modular branching here.
Login to comment on this ticket.