On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote: > Daniel Mach <dmach@xxxxxxxxxx> writes: > > The API is clear: DNF expects additional 'modulemd-obsoletes' YAML > > documents in modules.yaml. The new document format is getting into > > libmodulemd and there's going to be documentation on how to write it. > > > > Then there's a question how to get the documents into modules.yaml. From > > my perspective, it's up to Fedora infra/releng/packaging people. Whether > > it should be in dist-git, git repo (similar to modulemd-defaults or > > comps), PDC, Bodhi (similar to updateinfo) or somewhere else - that's > > entirely their call. > > I think the package/module maintainer should be able to set the EOL and > obsoletes for their module in a simple fashion, preferably without > requiring to create tickets for releng or anyone else. So that leaves > dist-git as the only option, right? > I also like the idea of having EOL data in dist-git in hands of the packagers. The problem is that a compose process run by relengs does not use dist-git at all. It picks up builds from Koji and data from various git repositories. The various git repositores is where the module default profiles live. Problem is that the various repositories are not dist-git. They have a rigid commit access by a few people. Those are not packagers. We could create a dedicated repository in dist-git for collecting the EOL data from various module maintainers and give the module maintainers a commit access there. But the problem with dist-git is that a special repository does not fit into the namespace schemata (rpms, modules, tests). We could create a dedicated repository on pagure.io instead, give maintainers a commit access there (the account system is shared with Fedora, I think) and confugure pungi (a tool run by relengs to make composes) to read EOL data from there. But there still had to be a manual step of granting the commit access. Another option would be adding the EOL data into modules dist-git repositories. To the same branches where modules are built from. But a different file. Pungi would enumarate all module builds directed to a compose, locate their dist-git sources by mapping name:stream to git://src.fedoraproject/org/modules/name.git#stream and download EOL data from there. That would enable module maintains to control EOLs simply by pushing an eol.yaml file into the branch of the module. Wouldn't relengs object that it's not accountable because the EOL data can be updated asynchrously of module builds and tagging in Koji? And isn't that what we want to acheive -- EOL data independent from the module builds? Alternatively we could append EOL YAML document to modulemd YAML document in the dist-git (a YAML file can contain multiple YAML documents) and rebuild the build. That way the EOL data would get together with the modulmd to Koji and to the compose. But that would bind the EOL data to module builds. If we wanted to EOL a module stream, we would have to make an unnecessary module build. Would it be still worthwile? -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
