Thoughts on Fedora Server lifecycle

Stephen Gallagher sgallagh at redhat.com
Mon Nov 11 12:36:26 UTC 2013


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

On 11/10/2013 02:48 AM, David Strauss wrote:
> I prefer keeping server on the same track as mainline Fedora
> releases unless we opt to add an *additional* LTS periodically. The
> current rapid release rate has been critical to the tight cycles of
> innovation for projects like systemd.

Well, that's basically what I described in this, except that only the
"LTS" (can we use "LTM" instead for long-term maintenance? We don't do
commercial support) would actually be maintained.

We'd always coordinate a release with the Base group (I *think* that's
what you mean by "mainline Fedora releases", but we'd have slightly
different expectations of maintenance on them. The released branch
would have controlled updates, maintaining compatibility. The preview
branch would remain on the current "firehose" model (to borrow spot's
term). Unlike the current model, each time a new preview release or
stable Y release (as in X.Y version) came out, the previous release on
that branch immediately drops support. (Which is likely fine, as if
you're already on the preview branch, moving to the next preview
release should be invisible to you through a yum/dnf update.)

So this gives us several advantages here:

1) We have only one branch that requires care and feeding: the stable
release branch. (Well, and a six-month overlap period that is
security/data-loss only fixes).

2) The preview branch essentially becomes rolling-release, with
regular installer checkpoints. The only variance from "true" rolling
release would be that it assumes that you will continue down the
stable path when that branches by default.

3) The preview branch is simultaneously fast-moving while still
providing an eighteen-month cycle to land bigger changes like Wayland,
an anaconda rewrite, DNF/Hawkey, etc.



I don't think we want to have the preview branch be *exactly* like
Rawhide, though. I think we'd probably want it to follow a policy
similar to "Branched" today where we maintain things for at least
three days in -testing before landing it in the preview stream. That
number of days is certainly up for debate.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKAz0oACgkQeiVVYja6o6PlmgCgqV1rjEQjoVAP/3YNjpef25+4
2+UAn1nfmg1RyQ+Pdr2GMdoLuu0ciV0K
=miUl
-----END PGP SIGNATURE-----


More information about the server mailing list