On Wed, Nov 28, 2018 at 3:07 AM Brian (bex) Exelbierd <bexelbie@xxxxxxxxxx> wrote: > 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. We have a lot of flexibility with all these technologies. What we need to achieve through our processes - CI, the release process, etc, is to enable users to take advantage of the technologies to achieve their goals - to get their work done - without having new problems thrown at them - excessive complexity, instability, etc. > 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 term "bootable-base" concerns me - because it could be interpreted to mean a minimal bootable set - just enough to get systemd and dnf running, perhaps. In another mail, you explained what you meant as "light up the machine level [...] and get containers/flatpaks/etc running". What does it take to get containers running usefully? It probably looks quite a bit like Fedora CoreOS. What does it take to get Flatpaks running in a useful way to users? - you need a full desktop environment - something like Fedora Silverblue (or the default install set of Fedora Workstation if you prefer loose packages). While the Fedora release today contains a lot more software than this "core operating system" - generally our release processes today are targeted at trying to release a stable core operating system - and this is something we can't lose if we start changing around how things work. It's not that I don't think the maintenance of glibc and gcc is really important, but if we refocus our release processes only on that, and one day a broken wpa-supplicant rebase lands and half our users lose networking - that would be a really poor outcome for Fedora. > 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. Fedora needs to be an operating system provider, not just an operating system toolbox provider. There are a lot of use cases for the "operating system toolbox" - To build the operating systems that Fedora releases - CoreOS, Workstation, etc. - To create the containers, Flatpak runtimes, and Flatpaks that Fedora releases - For users to create application containers - To create development environments (pet containers) - For adventurous users to create new, customized operating systems but you can't do integration testing on operating system toolbox, because the whole point is that you can integrated it any way you want and only the end user defines what is broken and what is working. Producing a *quality* operating system requires us to focus our processes on the integrated operating systems that we produce, on the applications we produce - and that's what our processes should be around. Could we replace the current 6 month release processes with an alternate set of processes around multiple rolling branches? It's certainly a possibility, but it's going to be very difficult to get a high level of stability - a level of stability that is acceptable to all end users - without a process where the *entire operating system* gets beta tested before being pushed out. If we want to move in the direction of rolling releases, the first step is to get the continuous integration testing and gating in place to make rawhide consumable by a broader set of people. That would be incredibly useful even if we keep the current 6 month tempo, but essential if we want to move to a rolling stable model. Until we can demonstrate that, it seems really premature to talk about rolling stable models. Owen _______________________________________________ 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
