On Thu, Nov 15, 2018 at 12:00 AM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On 11/14/18 2:42 PM, John Florian wrote: > > > I still don't understand what makes updating these for a *new* release > > significantly easier than an *existing* one. So let's just say GNOME > > (or whatever) comes out next month with a new major release we want to > > showcase. Why is it necessary to have a Fedora 30 to be able to realize > > this update. What is so difficult about providing this for Fedora 29. > > I'm trying to understand why these upstream updates can't be decoupled > > from the Fedora release schedule. > > Well, there's the problem all rolling releases have with that: > The user (mostly) has to accept changes when the distro pushes them. > If you push major updates at release boundries, users can choose to stay > on the older release until they are ready to devote time to the upgrade. > > Some users are fine with change any old time and adapt, but others > dislike that to varying degrees. 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. Building on a lot of ideas already mentioned and adding a few more, could we do something 'radical' and try to do rolling releases 'right?' Warning, the below kind of destroys the release concept or pushes us to actually do more "releases" but with less software tied to the release. Can we define a core of software using the Silverblue model that supports booting the hardware. This lets us define LTS as a set of hardware that we will keep running. This should solve most of the goals around extending our lifecycle. We can explicitly announce new hardware support and support that we are dropping as we push out new OSTrees. We'd have one tree we support. I'd look to our kernel friends to set the cadence on this. This would become the base for QE of everything else. The premise would be that declining an update should be a temporary and deliberate decision with the goal being to, ideally quickly, get to a point where the update can be accepted. A lot of us do this today already when we delay updates because of travel, conferences, or major projects we have to finish without risk. To be clear, updates are still opt-in, but there is little to no promise of support if you opt-out. I'd define the goal here as "everyone is running the latest core." Everything else (simplified statement) becomes an 'app' that can be updated. This includes desktop environments. We make all upstream supported releases available. This means that if, for example, LibreOffice drops a release for maintenance it also drops out of Fedora. This also means that we don't just add modularity/flatpaks/contains, we need to embrace them. The core is necessarily small. There may not be a central libfoo that a dozen applications can depend on. They may all have to know they need libfoo and get rebuilt and "updated" when there is a security fix in libfoo. This also means that refusing core or app updates may mean that your apps/system eventually stop working. I think this is reasonable to push onto users because upstreams are, by and large, also interested in great user experiences. They aren't going to ordinarily make big changes that destroy the user experience from release to release. They want to keep their users as much as we do. As long as we echo their updates, and provide warning on what changes to expect, we can give people the information they need to make decisions about updates. I think the same thing can be true for the server. I understand that this is not necessarily the best server experience for production environments, however, if we are going to be a place where we innovate in the operating system, we need people running and testing that innovation, not waiting on others to do it. I've written all of this without my "Red Hat" on thinking solely about our community and how I see it (for certain definitions of 'see' and only on some days). I have no idea how RH would feel about a Fedora that looked like this and I look to my friends who work directly on product to comment. It could create a situation where the only non-upstream supported app versions are those that RH maintains in Fedora. Maybe they start maintaining those in CentOS (see below) - I don't know. I also think this opens up an even greater opportunity for partnership with our friends in CentOS. How do we work together to make it even easier for users to consume both distributions to meet their various use cases? How can we cooperate with their SIGs to push stabilized innovation into CentOS faster for longer term consumption? Not everything in CentOS comes from RHEL, let's take advantage of that. This has gotten long, so I'll stop here (and add a few PSs :D). regards, bex PS: I realize that I am mostly restating the "half-rolling" argument, describing mobile phone updates, and repeating many of the comments that have been made about modularity/flatpaks/containers. But I haven't seen them stated in this thread as a path forward for Fedora. PPS: After writing all of this, and reflecting on the fact that I am sitting in a conference populated mostly by employed developers running Windows (and some Mac and Linux), I don't think this change (or others mentioned in this thread so far) increases our desktop adoption significantly. I don't think we are losing users to other non-Linux platforms over update cadence. I'm also not convinced that the majority of Linux users chose their distro primarily over this concern either. I'd be interested to hear these conversations restated in terms of increasing adoption beyond just getting on to the shipping list at Hardware vendor X. If the vendor isn't going to push Linux/Fedora, then what are we going to do to become a chosen option, not just a viable one? _______________________________________________ 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
