On Tue, Nov 20, 2018, 16:43 Brian (bex) Exelbierd <bexel...@redhat.com wrote:
> On Thu, Nov 15, 2018 at 6:43 PM Jiri Eischmann <eischm...@redhat.com> > 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 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.) 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@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@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: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > -- > Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com > Fedora Community Action & Impact Coordinator > @bexelbie | http://www.winglemeyer.org > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
