On Thu, 6 Aug 2020 16:45:15 +0200
Miro HronĨok <mhroncok(a)redhat.com> wrote:
Fedora has experimented with default modular streams for several
releases and we seemed to be at an agreement that the experiment has
failed:
See
https://pagure.io/fesco/issue/2406 which includes links to
relevant previous discussions on the topic. Admitting that default
modular streams are bad took as nearly two years, despite a few loud
and persistent individuals pointing it out since the beginning.
While I understand the original idea behind the concept of default
modular streams concept, shipping defaults via non-modular content
has been proven superior to default modular streams -- it has been
proven that default modular streams cannot be better than nonmodular
defaults and that they can only try to be as good as them, while they
are currently technologically failing to do that:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
I agree.
The currently proposed modularity objective for Fedora admits that
this won't be fixed until ta least Fedora 35 and later:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
The current modularity tech-lead strongly discourages default modular
streams:
https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122310
https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122502
Yet despite all this, we got a proposal to allow default modular
streams in ELN. The messaging about this proposal suggests that
later, default modular streams might be proposed for Fedora as well.
"""At present, these rules will apply only to Fedora ELN, but are
written in such a way as to be reusable for Fedora and EPEL in the
future through another Change Proposal.""" --
https://fedoraproject.org/wiki/Changes/ModularPolicy
This make the policy less clear than it needs to be. It spends too
much time talking about non-ELN Fedora and not enough time getting
into the ELN specifics.
This wording also seems like a way to sneak in modularity through the
back door. I know it explicitly says it isn't, but it still smells
bad.
If this experiment goes ahead and proves successful, then I expect
there will be lesson learned and the policy will be changed before it
is adopted for Fedora releases. Surely, writing the policy for Fedora
in general can wait until after some ELN experience is gained.
Fedora has decided that default modular streams are no-go. While I
admit that such a decision can be reverted at any time based on
significant changes in the technology, such changes have not happened
and are not planned. Yet strong supporters of default modular streams
try to allow them again and again, despite the enormous amount of
feedback they've received including the feedback from the current
modularity team and tech lead.
I do not recall any discussion from the modularity advocates of any
design level issues, nor of any proposals to address them. I do not
believe that any changes in the technology are forthcoming. Indeed
the need for such changes does not even seem to be acknowledged.
I sincerely don't understand the RHEL's need for default
modular
streams, but when I tried to query the motivation behind this, the
answers haven't made it any better:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
I anticipate great consternation in the CentOS and EPEL user
communities when RHEL decides to change some default modules. It is
my impression that modularity has caused problems for the CentOS and
EPEL developers:
<
https://lists.centos.org/pipermail/centos/2020-August/351261.html>
These problems have delayed the delivery of CentOS 8 and EPEL 8 and
leave a poor impression of the quality of RHEL 8. Maybe some RHEL
customers are wildly enthusiastic about modularity, but I don't see it
in the CentOS community.
The idea that we let the maintainers decide how they want to ship
the
default content is exactly what failed in Fedora in the first place.
But if RHEL people feel strongly that we need default modular steams
to succeed, so be it. What I don't understand is why do we need this
in Fedora (ELN). It boils down to this: Is ELN part of Fedora and
should it follow Fedora's feedback and Fedora's opinions, or is it a
RHEL project executed in the open, with decisions made behind closed
doors?
+1. From here ELN looks pretty closed. So does modularity.
I've heard several times that we need to have default modular
streams
in Fedora ELN to have a place to test them. In my opinion, we had
this place, it was in Fedora, we have tested them and they failed.
Hence I don't understand what's more there to test.
Many of the modularity problems manifest themselves at Fedora version
upgrades. I do not see how default modules in ELN will fix this.
Also, ELN does not provide an installer, limiting the availability of
ELN and the usefulness of this testing. If ELN were a viable
alternative to rawhide and used in the wild, then this testing could
receive actual user feedback. The many FESCO tickets were the result
of user experience.
OTOH, why don't just let the ELN SIG do this if it doesn't
affect
"Fedora proper"? Because I think it does. Since the beginning of the
ELN project, it has been said that it ships Fedora rawhide content,
built differently. Yet if we ship the default modular streams content
in Fedora ELN and the nonmodular defaults in Fedora Rawhide, suddenly
we ship different things, unless we have technical means to ensure
the content is synchronized.
I too find that the proposal fails to describe the relation between
rawhide and ELN. There's no way this proposal should be approved
unless the gap is closed. I would like to see the policy require
synchronization between rawhide and ELN and that tooling to enforce
this policy be in place as prerequisite.
When the ELN proposal was discussed, several package maintainers
(both from Fedora and RHEL) proposed to have an eln branch. It
received a big NO because the content would diverge and keeping it in
sync would be (close to) impossible.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
..and many times more...
Fedora ELN should not be a fork. Yet (some of the) default content of
Fedora ELN would be built from modules, which packages built from
different branches. Has the objective been changed? Is having
separate branches for Fedora and Fedora ELN no longer a big NO? What
changed?
How does ELN accomplish the state of being not a fork and different at the
same time? How does this affect the rest of Fedora? If it doesn't,
then why is ELN part of Fedora? If it does, what is the affect and
where is it described?
I am worried about the divergence between Fedora and Fedora ELN. I
am
worried about certain maintainers only maintaining their modules
without upgrading packages in rawhide -- and a need of a large
volunteer-driven effort to backport improvements and fixes from
modules to nonmodular packages: From Fedora ELN to Fedora. This seems
wrong to me, as I've always considered Fedora to be the upstream of
RHEL (and by extension of Fedora ELN) rather than downstream.
When I expressed this concern in the "RHEL 9 and
modularity" thread,
the discussion went nowhere:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
(and replies)
I believe that allowing default modular streams in any Fedora project
is a bad thing to do before the technology sees large design-level
changes. I believe that RHEL completely ignoring Fedora's feedback is
a very sad thing to happen. I believe that having default modular
streams in ELN will negatively affect general Fedora packagers. But I
realize that this is juts one person's opinion. At FESCo, I try to
represent the opinion of Fedora package maintainers, not just my own.
Hence I am sharing my concerns here to hear feedback from others.
ELN is a Fedora project. Thus I ask: How do default modules in ELN
benefit me, a developer who uses Fedora as my platform of choice? How
do they benefit other members of the Fedora community?
The Benefit to Fedora reads:
<
https://fedoraproject.org/wiki/Changes/ModularPolicy#Benefit_to_Fedora>
This policy makes explicit what packagers can and cannot do with
Modules in Fedora, which should avoid future issues like those
that were seen during the Fedora 31 and Fedora 32 cycles.
This sounds like damage control. It does not describe in any way how
adopting this change would be an improvement! I think this is bogus
and disrespectful. Please describe some real benefits over the status
quo. This proposal should be rejected unless positive and concrete
answers are provided.
Where's the "How to test" section for
<
https://fedoraproject.org/wiki/Changes/ModularPolicy>? One of the
stated objective is that this is a test bed for default modules in
Fedora.
I believe that modularity in Fedora has deep and fundamental design
problems. I believe that a policy band-aid is not a solution to these
problems. I am glad that FESCO acted to limit modularity and
encourage FESCO to proceed with caution and due diligence. My
experience is that modularity was hyped with generalities and few
specifics and yet managed to fall short of expectations. I find that,
even after all these years, end-user and general developer
documentation for modularity is sorely lacking. I am disappointed
that responsibility for modularity maintenance was moved to another
team while there were major outstanding design problems and that the
new team does not seem to have the remit to fix these problems.
FESCO, this proposal is inadequate. It does not provide any benefit
to Fedora, it does not describe the relation between rawhide and ELN,
and it seems to be over-reaching an a way that leaves a bad taste in
my mouth. Please reject it.
Jim