I want to jump in on one part of this ...
On Thu, Oct 24, 2019 at 10:40 AM Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
FXX: fish 3.x is non-modular, stream 4.x exists
FXX+1: fish 4.x is non-modular, stream 3.x exists
* If user wants to stay on 3.x, he needs to enable stream explicitly
*after* upgrade and then downgrade the package (which is actually
unsupported).
* If user wants to stay on 4.x, he needs to enable stream explicitly
during FXX (which is totally fine), but after upgrade he has to
explicitly disable it.
Obviously you can have 3.x stream for FXX and 4.x for FXX+1, but that means:
* Maintainer has to maintain that version *twice* (modular and
non-modular version)
* Nobody can guarantee that those will be compatible
Wearing my "council" headgear, I look at our mission statement and the default streams debate and feel like this drives to the heart of it. "[Modularity enables] Fedora [to create] an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users." With the ability to change default streams, and using Igor's example above, I could produce a Fedora spin that defaults to fish-4 easily. Yes, this means that I, or another packagers, needs to maintain a 4 stream, and that I as the spin master need to ensure the components I am selecting all work together.
More simply put, I feel like we are talking about Fedora's repo as a singly defined "thing." Yes, it is one repo of code, but modularity lets me "see" it as different versions, in many ways similarly to database views. We aren't trying to define the one true Fedora, we are instead defining the Rawhide version of Fedora and we should probably trend toward making that look like the Workstation Edition (our most, aiui, popularly used output). Everything else can use modularity to get what they want as default, aiui.
regards,
bex
_______________________________________________ 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
