On Thu, Nov 15, 2018 at 6:43 PM Jiri Eischmann <eischmann@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