On Thu, 18 Jun 2020 at 15:25, Josh Boyer <jwboyer(a)redhat.com> wrote:
On Thu, Jun 18, 2020 at 9:05 AM Igor Raits
> -----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 , 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 . 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
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
> > 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,
you can change the artifact type while keeping interface the same and
it would be a _HUGE_ win because it would make modularity finally
understandable for mere humans and better maintainable.
Namely, modules should become rpms and therefore obey standard rpm rules.
Thanks for looking at this
> 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.
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: