On Fri, 19 Jun 2020 at 01:59, Josh Boyer <jwboyer(a)redhat.com>
> On Thu, Jun 18, 2020 at 5:51 PM clime
> > On Thu, 18 Jun 2020 at 15:25, Josh Boyer
> > > On Thu, Jun 18, 2020
at 9:05 AM Igor Raits
> > > <ignatenkobrain(a)fedoraproject.org> wrote:
> > >
> > > > -----BEGIN PGP
> > > > Hash: SHA512
> > >
> > > > On Thu,
2020-06-18 at 08:44 -0400, Josh Boyer wrote:
> > > > > Hopefully that provides some context
and helps FESCo and the
> > > > > community understand where Red Hat is headed with modularity on
> > > > > Enterprise side.
> > >
> > > > Sadly no. It
helps to understand your plans, however it does not
> > > > to understand the reasons behind, whether you can't change UX in
> > > > RHEL 9, or you think that technology is good enough for your
> > > > 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,
> > Hello Josh,
> > 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
> I'm not sure I entirely understand what you mean, but
it sounds like
> you have some interesting ideas.
> I'm looking forward to seeing what you and the
community can build
> from them, and how they could be brought into RHEL 10+! That kind of
> collaboration is what makes Fedora great.
I know this probably won't change anything because this was mentioned
many times (by me at least) and nothing has changed but still...
Currently, modules are essentially yum sub-repos, they are not really
"modules", instead they are collections of rpms that reinvent rpm-like
relations (obsoletes, requires, build-requires, etc.).
There is no reason for this wheel-reintervention. Modules (the
collections) can be simply squashed into an rpm by automation and this
resulting rpm can go to the modular repo together with other modules.
That way we don't have two types of objects we complex inter-relations
but only one we well-known behavior.
I wonder if this is clear to everyone but nobody really cares or
doesn't really want to say it or I don't know.
Is this clear to everyone? I mean either I am stating an obvious stuff
that nobody really considers worth typing or idk.
How would this work when there are optional rpms in the module?
You do not need to install every rpm in eg the php module (different
graphics/database backends) for that module to be useful, but every version
of the module will have the rpm as an option which wont work outside a
module of multiple rpms.