I'm not sure it needs to be mentioned in the change proposal - but there are some caveats to this as it applies to the workstation:

 * There are no plans to add any user interface to enable/disable modules in the GNOME Software user interface.
 * If we even want graphical applications from enabled modules to appear in GNOME Software, someone is going to have to put work into appstream enabling modules, and into filtering the appstream data based on enabled modules.
 * For Fedora Silverblue, if we want users to be able to layer rpms from modules, then rpm-ostree will likely need work.

For the Workstation in general we want to move to a model where the system install set is stable and enables basic functionality, and containers are where you do sysadmin experimentation and development. Silverblue is the long-term version of this, but we encourage this way of working even for RPM-based installations.

So ideally documentation about trying out modularity on Fedora Workstation for something like a different version of nodejs would show doing that inside a container. (With the caveat that we're still figuring out what the recommended best practices are for pet containers.)

Owen

On Wed, Jun 20, 2018 at 1:14 PM, Jan Kurik <jkurik@redhat.com> wrote:
= Proposed System Wide Change: Modules for Everyone =
https://fedoraproject.org/wiki/Changes/ModulesForEveryone


Owner(s):
  * Stephen Gallagher <sgallagh at fedoraproject dot org>
  * Langdon White <langdon at fedoraproject dot org>


All Fedora installations will have modular repositories enabled by default, previously available, by default, only to Server Edition.


== Detailed description ==
In Fedora 28, the Server Edition debuted new modular functionality, allowing end-users access to alternative versions of popular software. Due to technical limitations with package-management software, it was not available for non-Server deployments of Fedora. Beginning with Fedora 29, all installations of Fedora will have modules available for installation and update. This will be done by merging the `fedora-repos-modular` sub-package back into the `fedora-repos` package.


== Scope ==
* Proposal owners:
The proposal owners need to coordinate the work of the DNF team and release-engineering to make sure that the repo subpackage merge only happens once the libdnf enhancements are stable. We will also need to prepare and run a Fedora Test Day with the QA team.

* Other developers:
The DNF team is already committed to providing the necessary changes for libdnf in Fedora 29.

* Release engineering:
#7561 [https://pagure.io/releng/issue/7561]

** List of deliverables:
All Fedora installations

* Policies and guidelines:
No alterations to packaging guidelines are required specifically for this change

* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NBD45XW5275VWVTLEYH5IHAJBK5T35ZF/