On Tue, Nov 12, 2019 at 10:26 AM Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org> wrote:
The question arises, what people are supposed to do when they modularized content because
modularity is (was?) good tool to have "buildroot-only packages," "separate
lifecycle from Fedora" and "no difference from normal packages."
Second was rightfully prohibited by FESCo, first is making people not happy. Third one is
not true.
I basically had to go back, remove 28 out of 52 Fedora modules because tooling is not
improving and policies are being more restrictive.
You say we need to improve tooling and iterate fast, fine. But why then
https://pagure.io/releng/issue/7662 is still not implemented? I understand that it is
opensource And everyone can contribute, but the fact is that people who work on Modularity
tooling is entirely paid by RH and those people are "responsible" to bring it to
Fedora and make it work. However, as written in the ticket "it is not a priority for
that team".
To be clear, the team that rejected that was the Bodhi team, not the
Modularity team. We do need to re-examine that; it just kind of fell
off the radar due to higher-priority issues.
So is it really about making tooling (writing new, or making existing
better) or about making those people to implement Fedora needs?
> For that we need to focus on the issue, which is, from my point of
> view: default streams and their differences from the ursine packages.
>
> One is caused by the lack of Ursa Prime, another is the upgrade
> functionality, and I guess the third one is the non-api and filtered
> packages in the module.
>
> P.S. I am not a member of Modularity team.
I agree with Aleksandra here. And we *did* establish that our policy
going forward is that we will forbid any default stream from providing
non-API content. (Filtered out packages are orthogonal to this.)