Owen Taylor wrote: > My particular interest is in what I consider the simplest use case - > taking an existing leaf-node application (desktop or otherwise), creating > a module that only includes that application and is not meant for building > on top of, and creating a container or flatpak out of the module. > > If we want to encourage maintainers of existing leaf-node applications do > this - to move into the modularized world - then having to go through this > process and also the container review process: > > https://fedoraproject.org/wiki/Container:Review_Process > > Seems like a pretty large barrier and discouragement - and getting > software into Fedora is already hard compared to the alternatives! The complexity is inherent in Modularity. Instead of doing a simple RPM, you are now doing 3 separate deliverables: 1. the RPM 2. the module, and 3. the container, which can all contain errors, so they all need reviews. > I'm wondering how we can streamline this case. Can we define some subset > of modules that are simple enough that we can do all the checks that need > to be done automatically? Does it make sense that in some cases we should > skip the rpms/modules/containers structure in dist-git and just add > module/container metadata along the RPM? Oh dear, no! There is room for mistakes in each deliverable. Even an apparently "simple" module or container can contain conflicting packages (probably pulled in from different dependency modules) that breaks it. If you want to avoid having to get 3 items reviewed, then you should only produce 1 item (the RPM) to begin with! You have to realize that by introducing modules and containers, you are adding a huge amount of complexity that eats up our manpower, manpower that we are already lacking. I am particularly worried about the combinatorial explosion of module combinations (since the plan is even to allow mixing&matching arbitrary module versions willy-nilly) which are just plain impossible to test exhaustively. Modules and containers are a mistake. Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
