On Wed, Nov 28, 2018 at 1:49 PM Brian (bex) Exelbierd
On Wed, Nov 28, 2018 at 1:31 PM Igor Gnatenko
> On Wed, Nov 28, 2018 at 1:14 PM Brian (bex) Exelbierd
> <bexelbie(a)redhat.com> wrote:
> > On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson <pbrobinson(a)gmail.com>
> > >
> > > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd
> > > <bexelbie(a)redhat.com> wrote:
> > > >
> > > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy
> > > > > Paul's proposal was definitely a one-time pause for the
> > > > > state. He requested we follow-up with additional questions and
> > > > > suggestions so I'm questioning and suggesting taking it a
> > > > > further. We talk about rolling releases, but people are
> > > > > to rawhide instability. What does it look like if the
> > > > > happens on top of an otherwise stable platform where
> > > > > compilers, libraries and core system tools are held steady, but
> > > > > on top move fast? Maybe you don't need an F30.1, maybe it
> > > > > just keeps getting nice incremental updates for as long as the
> > > > > editions want to stick with it. Variable lifecycle or cadence
> > > > > open up these kinds of options. Some things are better fast.
> > > > > things are better slow.
> > > >
> > > > This. Yes This. +100
> > > >
> > > > I think that Fedora's role as an innovater in the OS space means
> > > > should be aggressively exploring this. Rolling Releases,
> > > > 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
> > > > 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
> > > > 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
> > > > at the speed of the upstream, the user's desires and the
> > > > 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
> > > > to change often for most use cases reduces the matrix considerably.
> > >
> > > The above doesn't make sense, you're saying "move as fast as
> > > and "a base that doesn't change" in the same context, which
> > I've failed to be clear - sorry about that. Let me try again.
> > Please remember that I tend think from the lens of user space, not
> > kernel space. So there may be detail errors in this, I am hoping the
> > concepts are valid though.
> > In general, I can run various versions of my applications against
> > multiple different kernels, for example. Therefore, if I have a
> > kernel that changed once a year, it isn't going to, for many
> > applications, stop me from changing versions multiple times during the
> > year. Therefore if Fedora had a stabilized bootable base, I could
> > move my applications at the cadence of upstream, or a stabilized
> > release (not at all) or at the speed in the middle I want. Fedora
> > might not build the entire range of that, but I am not prevented from
> > choosing amongst multiple Fedora provided options (stable vs devel or
> > all supported upstream releases, for example).
> So you mean that you want CentOS stable base and latest software you want?
Nope. I want CentOS to serve their user base. If the CentOS project
chooses to formally become part of Fedora and to release a
longer-maintained base to their users under the banner of our mission,
I welcome them with open arms. But, that is their decision.
I don't think Fedora wants to get into 10 year life cycles and that
level of backporting. But, accepting a new kernel/bootable base
shouldn't force me to take a new version of LibreOffice, for example.
So what you are saying here is what "first" version of Modularity was
about. And it didn't work out because of many reasons. One of them is
no useful CI infrastructure (still not solved) which didn't allow
packagers to remove useless BuildRequires for tests (because rpmbuild
is still tte way to run test suite).
If we can get commitment from people who maintain "minimal viable
base" to move their tests to CI and get FTBFS fixes in time -- it
> > The bootable base would change based on Fedora's needs.
> > decide want to new kernels (again sorry for my failings in this field)
> > every 6 months to introduce new drivers and hardware support. Someone
> > who wants faster can self-build for their community/needs more
> > frequently or a hardware vendor might want a kernel that doesn't
> > change as often and is backported. Fedora may not build the whole
> > range here either.
> > > > I'd push Brendans' concept further and suggest that we try
> > > > eliminate as many of the compilers, libraries and core system tools
> > > > 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
> > > > 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?
> > "Eliminate the compilers" was meant to mean, make them modules or
> > non-bootable base components as much as possible. I realize that for
> > something like glibc that can be hard to impossible and for things
> > like Fortran a non-issue.
> > Communities have different needs, and every time we freeze or force
> > change we create challenges for those needs to be met. My point is
> > that by keeping our base to the "light up the machine level (another
> > hated idiom) and get containers/flatpaks/etc running" we can allow the
> > builder to focus on their community's needs or the user to get their
> > own too-fast/too-slow balance.
> > What I'd like to forego is the long "what is base" conversation.
> > pull it back to what does it take to boot the machine and get
> > containers/flatpaks/modules running. Everything after that should be
> > flexible, even if we put down requirements and rules for the use cases
> > we want to tackle and the pieces we build and deliver.
> > > > I recognize that I, like most people, see the world through the lens
> > > > of my specific use case, but remember, "Fedora creates an
> > > > platform for hardware, clouds, and containers that enables software
> > > > developers and community members to build tailored solutions for
> > > > users." As long as we don't block a use cases arbitrarily
> > > > 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
> > > > debate.
> > >
> > > I agree on some of your points above, but TBH most of it reads like
> > > some form of marketing coolaid!
> > Marketing Koolaid (in the interesting and love sense, not the
> > pejorative) would be really good for Fedora right now, if we want
> > increased adoption and contribution. Flexibility to allow our mission
> > statement to keep being true is critical. I fully admit that my
> > skills are not in distribution building and that you and others in
> > this thread have those skills in greater capacity than I do. But I
> > don't hear anyone starting from the premise of our mission statement
> > and then moving forward. I feel like a build/distribution focused on
> > easing the build process and ability to provide across the full
> > too-fast/too-slow spectrum, even if we as a project don't fill the
> > whole spectrum, is crucial to Fedora's ongoing success.
> I have nothing against, but stopping release for some mysterious
> reasons seems bad idea, but if we get some specific goals which we try
> to achieve -- I might even support this idea.
I am not sure releases as a construct, are as useful in their current
form to us today as they were in the past. I (emphatically) do NOT
want us to stop producing and releasing new software. In fact, I want
it released faster and more often, but without the accompanying user
disruption of forced upgrade/rolling releases. I want our
editions/spins/labs/remixes/etc. to be able to assemble the Fedora
that meet's their communities needs from the amazing pool of
contributions the project as a whole has.
Fedora may not build or even endorse everything that is made, but this
allows our mission statement to be put into practice. It allows
Fedora to become the easiest distribution to base your solution on.
Yes, I fully support this.
> > > regards,
> > >
> > > bex
> > >
> > > > 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
> > > > > system together to fulfill the needs of their community per our
> > > > > mission statement. If my mythical llama herders need the oldest
> > > > > Office possible but the newest Rust packaging and whatever
> > > > > version of httpd that Fedora deems "stable", then that
is what I
> > > > > desire, even if the upstream or other non-llama herding users
> > > > > something different. However, I'd also push that we should
> > > > > reach a point where if a llama herder for non-llama reasons needs
> > > > > different httpd, they can just enable and use it (using the
> > > > > of modularity). In case it isn't clear, the
> > > > > includes the goals of every current lab, spin, and edition,
> > > > > and where appropriate together.
> > > > > _______________________________________________
> > > > > devel mailing list -- devel(a)lists.fedoraproject.org
> > > > > To unsubscribe send an email to
> > > > > Fedora Code of Conduct:
> > > > > List Guidelines:
> > > > > List Archives:
> > > > _______________________________________________
> > > > 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:
> > > > List Archives:
> > >
> > >
> > >
> > > --
> > > Brian (bex) Exelbierd | bexelbie(a)redhat.com | bex(a)pobox.com
> > > Fedora Community Action & Impact Coordinator
> > > @bexelbie | http://www.winglemeyer.org
> > > _______________________________________________
> > > 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:
> > _______________________________________________
> > 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:
> Brian (bex) Exelbierd | bexelbie(a)redhat.com | bex(a)pobox.com
> Fedora Community Action & Impact Coordinator
> @bexelbie | http://www.winglemeyer.org
> 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: