Hi Langdon, Thanks for all the work that went into the process and guidelines! 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! 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? I'd love to discuss with people at Flock. Thanks, Owen P.S. - I don't mean to discourage adoption of these guidelines for more complex cases, and as a way we can get started creating simpler modules. I'm just wondering how we can lighten the load on packagers. ----- Original Message ----- > The Modularity WG has proposed a set of guidelines[1] and a process[2] for > adding modules to Fedora and we would love your feedback. Our general docs > are on Pagure[3] if you need more background/further information. > Please share your feedback here or directly on the wiki page(s). You can also > file issues/PRs on pagure[4] if you have other comments/edits/etc. > > thanks > Langdon > > [1]: > https://fedoraproject.org/wiki/Module:Guidelines?rd=Fedora_Packaging_Guidelines_for_Modules > [2]: https://fedoraproject.org/wiki/Module:Review_Process > [3]: https://docs.pagure.org/modularity/ > [4]: https://pagure.io/modularity > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
