On Tue, Nov 20, 2018 at 5:12 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Tue, Nov 20, 2018, 16:43 Brian (bex) Exelbierd <bexelbie(a)redhat.com wrote:
>
> On Thu, Nov 15, 2018 at 6:43 PM Jiri Eischmann <eischmann(a)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 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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 | bexelbie(a)redhat.com | bex(a)pobox.com
> Fedora Community Action & Impact Coordinator
> @bexelbie |
http://www.winglemeyer.org
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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 | bexelbie(a)redhat.com | bex(a)pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie |
http://www.winglemeyer.org