On Thu, Aug 6, 2020 at 10:46 AM Miro HronĨok <mhroncok(a)redhat.com> wrote:
On 05. 08. 20 21:36, Stephen Gallagher wrote:
> FESCo has requested that I submit the module policy once more to the
> Fedora development list for discussion. Feedback is welcome.
>
> == Requirements for Default Streams
> * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN
> permits defaults streams that adhere to the policy below.
Since this has been discussed at lengths at FESCo and this is the first time it
has been brought here (thanks for doing it, Stephen), let me summarize my
concerns with allowing default modular streams in ELN.
I would like to know if my concerns are valid or if I am just biased. Sorry for
the long email.
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...
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
Those comments were from Daniel when talking about Fedora as it exists
today. Not about ELN. Yes, he discourages their use in Fedora.
However, ELN has a mission to be a bridge to future RHEL and that
distribution has committed to default streams as a business necessity
for multiple reasons (among them support lifecycle which is much
harder to address via non-modular content).
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.
It was written that way *at your request*. You specifically asked for
a proposal for "Fedora" that we could initially apply only to "Fedora
ELN". It seems disingenuous to now use that as an argument against it.
"""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
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 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...
Josh listed some of the key reasons behind default streams: that
enterprise customers don't like to learn new commands. So default
streams allowed us to package content with shorter-than-RHEL-lifetime
and still `yum install foo` would install something the customer could
use.
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.
I agree with this statement, hence why the policy expressly requires
"Changes to default streams *MUST* be approved
via a Change Proposal". This means that the maintainer must get FESCo
approval to become a default stream.
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?
Decisions will not be made behind closed doors, but Red Hat *will*
have a strong opinion on them. And if ELN diverges too far from Red
Hat's needs, the experiment of ELN will have failed. Red Hat is
committed to making its reasons for such needs as transparent as
possible, so claims of "decisions behind closed doors" are rather
alarmist.
That said, I cannot deny that there is a crucial balance to be struck
here and that, I think, is one of the key pieces that default streams
can help with. As I have said elsewhere in this email (I'm jumping
around while writing, so I think this part is below): ELN will
*always* be built from sources that are available for Rawhide to
deliver. In effect, it will be equivalent to installing Rawhide with
that module stream enabled in the kickstart.
In cases where Red Hat strongly believes that a particular alternative
stream in Rawhide is more in line with the needs of RHEL, a Change
Proposal will be filed with a request to have that stream become the
default in ELN.
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.
Because software never changes or improves over time. Right, I forgot
we gave up on Python after we discovered that its unicode handling
wasn't great...
Honestly, I don't understand your argument here. The *implementation*
had issues. Those issues have been identified and plans exist to
resolve them. We agreed not to put that in Fedora until we could prove
it was fixed.
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'm... not really sure what you're comparing here, but I'll try to
make it clearer.
* Anything that exists as non-modular content in ELN will have been
built from the Rawhide branch of the same non-modular RPM.
* The set of non-modular packages built in ELN will be a subset of the
non-modular packages in Rawhide
* Module streams built for Fedora Rawhide *may* also be built for Fedora ELN.
* Module streams built for Fedora ELN *may* be set as the default
stream in ELN. If so, those RPMs coming from the default stream *must
not* overlap the non-modular content.
Does that make more sense?
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?
See the previous statement. The module streams for ELN will be built
from the exact same YAML as the equivalent Rawhide module stream. Thus
what is being delivered is still "Rawhide content", it just happens to
differ about which is the *default content*.
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
I feel that this is highly unlikely since ELN won't be a deliverable
in the traditional sense of the term. If they were to do this, their
package would stagnate in Fedora. If that happens, that's what the
non-responsive maintainer process is for.
-- 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.
I guess we haven't been clear enough about the artifacts that ELN
produces. They are intended as a compose for testing/CI purposes
*only*. We will not be mirroring them or making them publicly visible
on
getfedora.org or anything of the sort. It's a bootstrapping effort
towards RHEL X+1.
I intend to make it VERY clear that working in ELN but not maintaining
that content in the rest of Fedora is unacceptable. That's part of the
reason behind the package comaintainership requirement in this policy.
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.
I understand your stance on the matter at large. I hope that my
responses above have provided you with at least some measure of
improved clarity.