I want to jump in on one part of this ...

On Thu, Oct 24, 2019 at 10:40 AM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to