Thoughts on Fedora Server lifecycle

Stephen Gallagher sgallagh at redhat.com
Fri Nov 1 18:52:21 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/01/2013 02:48 PM, Simo Sorce wrote:
> On Fri, 2013-11-01 at 14:30 -0400, Stephen Gallagher wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Related to my earlier mail "Server Admins: Why not Fedora?", I
>> wanted to specifically discuss some lifecycle ideas. Every few
>> months, people start shouting again for a "Fedora LTS" and people
>> generally respond with "we couldn't support that with volunteers"
>> or "go use RHEL/CentOS/SL".
>> 
>> Suppose for a moment that we did things a little differently in
>> the Fedora Server. We don't want to get out of sync with the
>> release cycle set by the Base Design WG, certainly. But at the
>> same time, I think we can come up with a fairly simple way to
>> maintain the Fedora Server for a longer time period.
>> 
>> I'm going to propose a lifecycle of eighteen months (with slight 
>> extensions for slippage) as follows.
>> 
>> Let's start talking about Fedora Server 1.0 (rather than Fedora
>> Server 21).
>> 
>> In my view of the world, 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.
>> 
>> I spent the last hour trying to draw up a decent timeline
>> graphic, but I am terrible at this and so I will instead attempt
>> to explain it in text. Please bear with me.
>> 
>> 
>> 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", and 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.
>> 
>> So yes, that sounds ambitious, but what do you think of the
>> idea?
> 
> How would you handle upgrades between N-1 -> N ?
> 
> Simo.
> 


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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJz+GUACgkQeiVVYja6o6PQUgCfbnrDfSvb/bdP6ubtjr6OIE/T
YwAAnjOmDvNhMu8EPadinlDK3hdNGhg5
=qYu2
-----END PGP SIGNATURE-----


More information about the server mailing list