On Wed, Nov 28, 2018 at 1:14 PM Brian (bex) Exelbierd <bexelbie@xxxxxxxxxx> wrote: > > On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > > > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd > > <bexelbie@xxxxxxxxxx> wrote: > > > > > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy <blc@xxxxxxxxxx> 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'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? > The bootable base would change based on Fedora's needs. Perhaps we > 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 to > > > 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? > > "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. I'd > 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 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 > > > 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. > 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 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@xxxxxxxxxxxxxxxxxxxxxxx > > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > 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@xxxxxxxxxxxxxxxxxxxxxxx > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxxxx > > > > -- > Brian (bex) Exelbierd | bexelbie@xxxxxxxxxx | bex@xxxxxxxxx > Fedora Community Action & Impact Coordinator > @bexelbie | http://www.winglemeyer.org > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
