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 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@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
