Modularity and all the things

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Starting a new thread since the old one is hard to navigate at this point.

Modularity is a distribution-level change and requires some mindset
shift from packagers and users alike. I understand the concerns some
people have, feeling it’s something new and half-baked that is being
forced on them.

We’re an open source community and in order to drive innovation, we
need to be able to try new approaches and technologies in the open,
not develop them without any input and hands-on experience behind
closed doors, later serving them on a silver plate. The feedback we’re
getting is extremely valuable, but some of it is too narrowly focused
on one specific problem area and not taking into account the other
aspects, requirements, or goals that we’re pursuing. Our objective is
still to deliver multiple versions, or variants, of our content across
releases or even distributions (think EPEL or CentOS). And it’s a good
one.

The concept of default streams was introduced to make modularity
invisible to anyone who has no interest in alternatives and wants the
system to operate as it historically has. Whether a specific package
is delivered via a module or not shouldn’t matter. (This does not mean
it should be hidden, just that it should have no practical difference
to the system.) This applies to both buildroots and runtime, leaving
the choice of whether to modularize or not to the maintainer.
Obviously, the implementation is falling short in this regard right
now, but we have solutions in development or under design. This
includes making the default streams available in the non-modular
buildroot via Ursa Prime or tracking the module enablement intent in
our software management stack, as Stephen suggested in the original
post.

While these issues are being resolved, we are considering temporarily
disallowing default streams in Fedora. I don’t want to abandon the
idea completely, as doing so reduces the motivation to actually build
modules and reap the benefits they might provide.

Yes, modularity still has some additional development ahead. We need
to improve the software management stack experience; we need to
revisit our release engineering SOPs; we need to stabilize and boost
performance of our infrastructure; and last but not least, we need to
improve the packager experience, providing more features to make the
creation of modules easier, as well as guidance, best practices and
policies that make it easy to collaborate. These changes are similar
to those for other useful but disruptive technologies that Fedora has
successfully introduced in the past.

I do believe we all intend the best, even if we sometimes disagree. We
currently don’t have any other proposal that would fulfill the vision
of our Objective and the needs of our users. The input here helps us
re-focus on the most acute pain points but the manpower and control we
have is also rather limited. If you want to and can help with the
implementation, I’d like to encourage you to do so.

P
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux