-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Thu, 2020-06-18 at 09:24 -0400, Josh Boyer wrote:
On Thu, Jun 18, 2020 at 9:05 AM Igor Raits
<ignatenkobrain(a)fedoraproject.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On Thu, 2020-06-18 at 08:44 -0400, Josh Boyer wrote:
> > Hello Fedora Community!
>
> Hi Josh,
>
> > I am a long-time Fedora Community member, and may be familiar to
> > many
> > through previous FESCo or devel list discussions and passionate
> > debates. However I write to you today with a different community
> > hat
> > on, as a lead Architect for Red Hat Enterprise Linux. The RHEL
> > organization has been following the modularity discussions within
> > Fedora, particularly around ELN, and often the question of what
> > plans
> > we have for modularity in RHEL 9 has come up. Our Fedora Project
> > Lead
> > and a number of FESCo members have reached out and asked if we
> > can
> > provide some perspective here, and I am both happy and excited to
> > have
> > that opportunity.
> >
> > As the Fedora Council has pointed out [1], we certainly
> > acknowledge
> > there are improvements to be made and have a team already working
> > on
> > them. They recently outlined their plans in conjunction with our
> > Product Management team in a Fedora Council call as well [2].
> > We’re
> > continuing to invest time and effort in this packaging solution
> > and
> > are confident that the team can deliver against their plan. It
> > is
> > somewhat of a new experience for all of us when Red Hat is direct
> > with
> > our product intentions, but we discussed the larger gaps we see
> > with
> > usage in RHEL and are putting our efforts towards solving those
> > gaps
> > with this plan.
> >
> > Modularity is important to RHEL and those efforts are already
> > underway. We will be leveraging modularity in RHEL 9 where it
> > most
> > makes sense. This is primarily centered around our Application
> > Streams concept, which has been well received by our customer
> > base.
> > Providing a consistent but improved experience is the base
> > requirement, which allows us to have continuity from RHEL 8 to
> > RHEL 9
> > and lowers the hurdle for our customers when upgrading from one
> > major
> > version to another.
>
> It is nice to hear that it is helping to solve problems in RHEL
> (even
> though I've heard many people saying that it is nightmare now). Is
> there a list of requirements that you have so that we could
> potentially
> develop something that would be useful to Fedora same as for RHEL
> 10+?
The dnf team is working to gather those internally. RHEL 10+ is
still
~5 years away, and while we're working hard to develop our product
roadmap, that's still far enough off that we haven't put much down in
terms of requirements :)
> > It is always good to push the boundaries and search for better
> > ideas
> > and improvements, and that is part of what makes Fedora great.
> > We
> > are
> > doing this in the context of the RHEL 9 release as well, so our
> > near
> > term timeline and requirements mean we are working on evolving
> > modularity, not a revolution or a replacement. We are excited by
> > ELN,
> > as it presents a possible space to allow those that want to
> > continue
> > to iterate on modules a place to do so without necessarily
> > impacting
> > the broader Fedora distribution in its entirety. It is my
> > personal
> > hope that we can use that opportunity to improve modules and
> > modularity in the open source, Fedora-first way we’d prefer. Our
> > near
> > term effort to improve the existing modularity implementation
> > ahead
> > of
> > RHEL 9 needs to occur, and we’d like to do that work in Fedora,
> > rather
> > than in closed product development. Longer term, we are open to
> > contributing to a better replacement that meets many of the same
> > goals. This is what makes our distribution ecosystem work well,
> > and
> > not having that upstream lessens the value we all get from such
> > experimentation in the open.
>
> While I support you that we should do it in Fedora, does this
> essentially mean that this technology is useful only for RHEL and
> you
> do not plan to develop it *for Fedora*, but rather *for RHEL in
> Fedora*?
I wouldn't say that, nor do I personally think that. I think there
is
value for Fedora as well. Matthew Miller has often given a common
example of having two streams of software that can build across RHEL,
Fedora, CentOS, etc. This is value for end user consumption, and
having older software available in Fedora is a usecase modularity can
help address. However, I would prefer to avoid discussing value to
Fedora in this thread. There are so many other threads debating that
already :)
Let's agree to disagree :)
> > Hopefully that provides some context and helps FESCo and
the
> > wider
> > community understand where Red Hat is headed with modularity on
> > the
> > Enterprise side.
>
> Sadly no. It helps to understand your plans, however it does not
> help
> to understand the reasons behind, whether you can't change UX in
> the
> RHEL 9, or you think that technology is good enough for your use-
> cases
> or any other reasons.
The base requirement is that the UX remain largely the same. As I
said, from a RHEL perspective, we need RHEL 8 and RHEL 9 to have
commonality so that our customers are not forced to learn something
entirely different to adopt RHEL 9. Improvements in the underlying
functionality are of course welcome and planned, but we are not going
to do something like replace modules with a different artifact type,
or add separate discrete repos per Application Stream, etc.
> Basically this email just says "We decided for Modularity in RHEL 9
> and
> we would like to do it in Fedora Infrastructure first".
Mostly, yes. We were told there was ambiguity on whether modularity
would be used in RHEL 9 or not. Very clearly it will, so I wanted to
get ahead of that.
Sure, I think this is answered quite clearly here. Thanks.
josh
- --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7rbDUACgkQEV1auJxc
Hh7+ORAAg1jmZZvcCmqeW6YCi44eFnXERea6Z2QTXSVmZYINFVoATQeuzDFElEOF
ETi72MX7bAw3KwjMJU++vlOKof8WpBHV2fEC1ldUeq2vk+FrCvBKEyiGrXmtkXnu
hRJ7BzqBBfcPyZzplpXBrXqFapr0vLYwvT9RRRThHWMvLaGneMUF/q4kPgKT+Pm3
+K8Vo5hDL8fCjw3XdnYNLaAkGGeR4XxJ13D/i+9JmGPd41kv2/eVrui5N/FTRC1L
a+cJXJSQiBE0iO7oe8kDtKvSmYUTSG0sZMRR15MastdxbRyYYDG6TVL99XYG1PuA
iGQXIJGIUdb81ttdPD/6gsefk/StSZKDL+CSLfCoQuqEdqBHhjha9W6WQVJxClMk
iSpVHGZpUF9mtsPqKQ3kV4q77w8M0Qz1GbqpLP2H+iVtzVtqQfRJ3QdD8PZDkuBu
+e40oTC5AOopo5P8/p/VD1um2G4K7d7GmspsOOGoNOVDUwEV3/KjXbW5CCeSOC1v
soEH41S8idQygVxI02+BrJTdNfJUrz+o6HaqmY4TfXZoXRe5jBX+9gj0JofFlis0
cgTuixHAljPT2btC7IP4xrdTr3WdCnZJAjaqTANYZclv/TGZeGTKap92pIV405nu
8cxjkd9mCHsL6mUApyIXxaro2yJ5y7ShRmWl5dO9+P1qeJjYqtY=
=OmeX
-----END PGP SIGNATURE-----