On Tue, Aug 22, 2017 at 9:53 AM Owen Taylor <otaylor@xxxxxxxxxx> wrote:
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?
We want to do exactly this and I would like the "trivial status" to evolve to this (before f27). We have already been struggling with how the guidelines talk a lot about "so there is this field but you really shouldn't fill it in because infra will do it for you." Specifically, Nick (cc'd) had some thoughts on this I know. However, right now, we have a couple problems:
a) the modules are mostly still the complex ones
b) not all the automation tooling is done yet
I regularly half-joke that the user-modifiable component of the modulemd should just be the srpm and the branch to follow and everything else is just automatic.
I assume you meant "metadata along the RPM" -> "metadata alongside the RPM" vs something else. If so, I think our further goal is that we have a tool that just takes an srpm as input and just generates the modulemd and then generates "container metadata" (at least dockerfiles for now) and then sticks it in the correct repository. We have some of these tools already. Ultimately, we could re-gen on updates to the rpms automatically.
However, I do think we want some separation so that if we want to base modules or containers on something other than rpms some day, we aren't tightly coupled. This may be a trivial consideration but it was the original thinking and if the tools above come to fruition it should be moot anyway.
I'd love to discuss with people at Flock.
yes, please, but, I think you are perfectly correct.. so :)
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
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
