On Tue, Nov 20, 2018 at 5:12 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > On Tue, Nov 20, 2018, 16:43 Brian (bex) Exelbierd <bexelbie@xxxxxxxxxx wrote: >> >> On Thu, Nov 15, 2018 at 6:43 PM Jiri Eischmann <eischmann@xxxxxxxxxx> wrote: >> > >> > Gerald Henriksen píše v Čt 15. 11. 2018 v 10:22 -0500: >> > > On Thu, 15 Nov 2018 14:38:12 +0100, you wrote: >> > > >> > > > I understand this argument, but I think more and more desktop users >> > > > are being trained that updates happen on a schedule they didn't >> > > > choose >> > > > and are hard to avoid. This is how most mobile operating systems >> > > > function. >> > > >> > > iOS prompts you for the yearly updates, and it can be avoided if you >> > > really want. >> > > >> > > macOS requires you to specifically choose the yearly update, though >> > > they may have changed with Mojave. >> > > >> > > Not sure about Android, but the fact that Google has had to twist >> > > things into a knot to try and get updates out to users indicates that >> > > upgrades to Android aren't being pushed out for the most part. >> > > >> > > Windows is the only one forcing upgrades, and it is perhaps one of >> > > the >> > > reasons that hardware vendors are showing more interest in Linux as >> > > people are now more willing to consider anything other than Windows. >> > > >> > > Really, the only place where forced upgrades are happening, are >> > > accepted, and seem to actually work are on the application side and >> > > that is because, demonstrated by the web browsers, frequent updates >> > > can be done unobtrusively and reliably. >> > >> > And with the named examples are you gonna get any support and updates >> > if you decide to hold off an upgrade to a newer OS? I doubt. >> > I can certainly hold off upgrade to Android 9 on my phone, but that >> > doesn't mean I'm gonna get any further updates for Android 8 from the >> > phone vendor. >> > There is a huuuge difference between "not forcing upgrades" and >> > "providing supported and secure way to stay on the current release". >> >> I think this tied up with one of the major problems we are trying to >> solve with Fedora Modularity, the "Too Fast, Too Slow" problem. > > > I think identifying which components move too slow or too fast would be a good start - even if those lists might depend on the specific user or use-case. I think this is a great way to differentiate various spins/labs/editions, however the OS as a whole needs to be able to allow as much as possible to flex as much as possible. I think that trying to define a core beyond "boots the machine" quickly leads to an endless rabbit hole. >> I am not sure it is bad for Fedora to only have a single supported >> "release." If you refuse an upgrade, you're on your own. If you >> refuse it because you're going on a trip, have a presentation, etc. >> and plan to do it later, you generally don't care. If you do it >> because you don't want your system to change, I am not sure Fedora >> should be your distribution of choice (I'll introduce you to my >> friends CentOS and RHEL). >> >> If we did a "stable rolling release base" that, described simply and >> incompletely, had a beta and stable option where you knew your >> hardware would work and your apps would run I think most users, >> desktop and server, would be happy. > > > What about aliasing fedora-N to "rolling-beta", and fedora-N-1 to "rolling-stable" (similar to what Debian does)? Every 6 months or so, rolling-stable users would get an upgrade to a fedora release that's been well-used and -tested for about 6 months. (Which I guess is what some people already do manually.) I agree that we need a beta vs stable pathway, but I am not sure having a release helps us. We can do version numbers if we need them for marketing, but I think some of what appeals about rolling releases is that upgrades are a non-event. We've basically accomplished that with Fedora today, except that we still make a big deal out of hte upgrade and hte new version number. Let's push it further to non-event status and instead talk about updates as new features and benefits, not a new version. (this is poorly worded - I am in a rush). regards, bex > > We only need to make sure that the upgrade path always works for, say, the last 4 fedora releases (or however many we need to support upgrading from). Upgrades from N-2 to N are already supposed to work (I think), so this shouldn't be too hard. > > (Also, silverblue would make this really easy, by "just" automatically switching to the new N-1 branch every 6 months, when N-2 hits EOL). > > That way, the number of supported fedora releases stays the same, and only the upgrade path needs to be reliable for longer. > > Fabio > >> We use the "beta" to find >> hardware regressions and to signal hardware we are dropping support >> for or adding new support for, and we use stable for people who want >> to get things done. Layer on Modules. containers and Flatpaks and we >> have the apps moving on their own speed on this base. Yes, it creates >> a matrix, but it one we have been working on CI to support already and >> one that I think users will actually embrace. They don't need to know >> the whole matrix, just how to adjust if the defaults aren't what they >> want. >> >> I think this gets us: >> * what we think the hardware vendors need (continuous support) >> without blowing up our version count >> * smaller QA targets for various pieces (and we are already planning >> all of these pieces) >> * a stable leading edge solution that by "pinning" your app version >> feels like a rolling release and a traditional release at the same >> time >> * reduce our work on keeping releases active and some of our >> backporting footprint >> * increases the footprint of people testing and using our innovation in the OS >> >> regards, >> >> bex >> >> > >> > Jiri >> > _______________________________________________ >> > 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 -- 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
