Server/Proposals/Server Lifecycle

Resources

This proposal comes from the following thread started by Stephen Gallagher on the server mailing list:

Thoughts on Fedora Server lifecycle

A relevant earlier proposal that is similar is Tom Callaway's Overhauling the Fedora Release Model talk from FUDCon Lawrence in January 2013.

Overview

This proposal is for a lifecycle of eighteen months (with slight extensions for slippage) as follows:

• We will start with Fedora Server 1.0 (rather than Fedora Server 21).
• We would build the Base Design as Fedora 21, Fedora 22 and Fedora 23 following mechanisms not terribly dissimilar to the present-day model.
• We would then create the Fedora Server atop this, delayed by a small amount < 1 month).
• We would use the latest Fedora Base bits as the platform and sync our pieces atop it at regular intervals, aiming for a finalized release every eighteen months.
• Up until the final release, each N preview release should be just a snapshot matching EXACTLY the Fedora Base release at that time. It should be usable (but probably won't get any extra QA time over the Base release). Then at the N.0 final release, it should get branched away and kept more tightly controlled. This doesn't mean that it can't get updates out of the Base branches, but they should be merged in when they're ready, not blasted in from the firehose.
• Each N.0 release essentially goes into maintenance mode at the moment of it's stable release. Real new functionality should head to N+1 previews and only get pulled back to N.x if it makes sense and someone is willing to do the work.

Detailed Walkthrough Of Timeline

Source SVG

• Let's start the discussion from Fedora 21. We would follow the Fedora 21 process closely until the base design is declared final (much as current Fedora is now). Ideally at the same time (but possibly delayed by up to a month), we would release "Fedora Server 1.0 Preview 1". This would be a complete, installable server operating system, but make it clear that it's a preview release that may not represent the final product.
• At Fedora 22, we release "Fedora Server 1.0 Preview 2", with the same caveats.
• However, at Fedora 23, we release "Fedora Server 1.0". At this time, we agree to freeze the interfaces and make clear demands on backwards-compatibility. For the remaining life of Fedora Server 1.x, it will be a stable platform (and understood to be extremely conservative with its updates).
• At Fedora 24, we now release two things: "Fedora Server 1.1", which will just be an updated installer with the latest versions of any package updates that have occurred in the standard install since Fedora Server 1.0". We will also release "Fedora Server 2.0 Preview 1", following the same guidelines as above.
• Fedora 25 would offer the "Fedora Server 1.2" updates roll-up and "Fedora Server 2.0 Preview 2."
• Finally, Fedora 26 would offer only "Fedora Server 2.0" as install media. At this time, Fedora Server 1.0 would become "security-fixes only" for the six months until Fedora Server 2.1 (to allow overlap to upgrade). As of Fedora Server N.1 of any release, the N-1 series is abandoned.

Questions & Answers

1. How would you handle upgrades between N-1 -> N ?
   • Well, that's part of the point of the .1 releases too. That's the point at which we should be re-testing fedup to major releases. Within a release, fedup shouldn't (must not?) be required. I.e. Fedora Server 1.0 -> 1.1 should be safe and clean with just 'dnf update', but 1.1->2.0 should go via fedup. (sgallagh)
2. Is Fedora Server going to have its own package repository?
   • Yes, the same way that Fedora 19 and Fedora 20 have different repositories. It's nothing new. (sgallagh)
   • This is quite a bit different, in that it's not tracking a fedora release. This would potentially mean "yet another" target for builders and 3rd party repos to support. I would much rather track the current fedora releases with better packaging, usability etc than spawn an entirely new structure. (Evolution)
3. In Fedora Server 1.0 you will have to install packages built for Fedora 21, however if the product that produces them stays on a short release cycle, by the time we go 1.0 there not even security updates anymore for them. So what do we do ? We force other products to do security updates for 24 months ?
   • Up until the final release, it really should be just a snapshot matching EXACTLY the Fedora Base release at that time. It should be usable (but probably won't get any extra QA time over the Base release). Then at the N.0 release, it should get branched away and kept more tightly controlled. This doesn't mean that it can't get updates out of the Base branches, but they should be merged in when they're ready, not blasted in from the firehose. (sgallagh)
4. "Updated installer"? Unless you mean something not anaconda, I'm not sure you'll be able to update the installer in Server 1.1 with the installer in Fedora 24, given that Fedora 24 is back to "unstable-ish". Why isn't 1.1 using the installer from 1.0?
   • I was mostly thinking of newer anaconda enabling more hardware/choices, but I'm certainly flexible here. If the costs outweigh the gains, obviously that's the wrong choice. (sgallagh)
   • About the only option really doable here is to have someone pick up Server 1.0 anaconda and do backports for pieces of functionality that

were added and are still covered by the underlying packages in f21-f23. It would be a micro-fork of anaconda at that point though. Definitely something to discuss with those developers. (jboyer)

1. When Fedora Server 1.0 forks, that is maintained in addition to building towards Fedora Server 2.0 on the now unstable Base? This is essentially the idea that Spot pitched at FUDCon Lawrence. If the resources to pull it off are attainable, I think it will go a long way but the requirements to do this shouldn't be underestimated.
   • We're talking about a much smaller version of the Fedora Project than he was. Here we're talking about a highly-constrained set of packages that makes up the Server default install, which we should be striving to keep as small as possible. This will keep our resource needs down with regards to

maintenance.

1. • Well, Base + Server. Base will be smaller, but still fairly sizeable or it woudn't be usable as a Base. So at the point you fork off Server 1.0, you're maintaining both of those package sets in Server 1.0. (jboyer)
2. How is this going to work without impacting the contributors working on Fedora Base?
3. What resource requirements will make this feasible?