On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd
On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy <blc(a)redhat.com> wrote:
> Paul's proposal was definitely a one-time pause for the reasons you
> state. He requested we follow-up with additional questions and
> suggestions so I'm questioning and suggesting taking it a step
> further. We talk about rolling releases, but people are skeptical due
> to rawhide instability. What does it look like if the "rolling"
> happens on top of an otherwise stable platform where fundamentals like
> compilers, libraries and core system tools are held steady, but things
> on top move fast? Maybe you don't need an F30.1, maybe it means F30
> just keeps getting nice incremental updates for as long as the
> editions want to stick with it. Variable lifecycle or cadence can
> open up these kinds of options. Some things are better fast. Some
> things are better slow.
This. Yes This. +100
I think that Fedora's role as an innovater in the OS space means we
should be aggressively exploring this. Rolling Releases, Tech-Driven
Releases and Time-Based Releases all have well known positives and
negatives. All of the work that has been done on Modularity,
containers, flatpaks, OSTree, and more, gives us the opportunity to
really re-think this. While it is true there are dozens (or more)
additional solutions to the too-fast/too-slow and the
incompatible-libraries problems, these technologies seem to be gaining
the most adoption across a variety of use cases. They are all also
generally well supported in Fedora and we need to aggressively push
them to achieve this goal or determine where the dead-end is so we can
move to the next innovation.
I personal am hugely in favor of us adopting a bootable-base model
that allows us to iterate the kernel and the various user-space pieces
at the speed of the upstream, the user's desires and the builder's
desires[^0] all at the same time. While this will require us to do
some level of NxM matrix building and testing, a base that didn't have
to change often for most use cases reduces the matrix considerably.
The above doesn't make sense, you're saying "move as fast as upstream"
and "a base that doesn't change" in the same context, which is it?
I'd push Brendans' concept further and suggest that we try
eliminate as many of the compilers, libraries and core system tools as
possible from this bootable-base so that those can iterate at their
own speed, perhaps 4 year for a laptop vendor and 30 day for a
experimental ARM device. Fedora as a project might not build output
for the whole range, but a build system that allowed us to help others
be successful would be a huge help here.
Again what do you even mean by eliminate the compilers? Also how do we
not change something core, such as a compiler, for 4 years while also
change it every 30 days?
I recognize that I, like most people, see the world through the lens
of my specific use case, but remember, "Fedora creates an innovative
platform for hardware, clouds, and containers that enables software
developers and community members to build tailored solutions for their
users." As long as we don't block a use cases arbitrarily and we
leave room for that innovation and service we are doing the right
thing. The debate about what use cases should be done fully by
Fedora, enabled for a SIG/WG via our build system or done externally
by those using only the parts that make sense for them is a separate
I agree on some of your points above, but TBH most of it reads like
some form of marketing coolaid!
Also it does account at all for any and/or all of the resources that
we'd need to even enact some of this, even if it's possible?
> 0: Builder's desires are the desires of the person who put the entire
> system together to fulfill the needs of their community per our
> mission statement. If my mythical llama herders need the oldest Libre
> Office possible but the newest Rust packaging and whatever random
> version of httpd that Fedora deems "stable", then that is what I
> desire, even if the upstream or other non-llama herding users desire
> something different. However, I'd also push that we should try to
> reach a point where if a llama herder for non-llama reasons needs a
> different httpd, they can just enable and use it (using the language
> of modularity). In case it isn't clear, the "builder's desires"
> includes the goals of every current lab, spin, and edition, separately
> and where appropriate together.
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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: