Thoughts on Fedora Server lifecycle

[Josh Boyer]

On Fri, Nov 1, 2013 at 2:30 PM, Stephen Gallagher <sgallagh at redhat.com> 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

"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?

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

So, 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 Blacksburg.  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.

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

I think it's a fine idea.  I think you need to clearly identify how
it's going to work without impacting the contributors working on
Fedora Base and what resource requirements you have to make that
feasible.  Note, resource requirements doesn't necessarily mean
"people".  It can be tool improvements, automation, etc.

josh