-----BEGIN PGP SIGNED MESSAGE-----
On 11/01/2013 04:02 PM, Josh Boyer wrote:
On Fri, Nov 1, 2013 at 2:30 PM, Stephen Gallagher
> -----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?
Sure, that's debatable. 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.
> 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.
Yes, agreed. I do think that this is a little more achievable than
Tom's original proposal though, since 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
> Fedora 25 would offer the "Fedora Server 1.2" updates
> 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
> So yes, that sounds ambitious, but what do you think of the
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.
Yes, certainly. If we think this is worth exploring, then we should
dig down into those details. I'm not going to attempt to do so at the
end of the day on a Friday though. I'm sure it won't be my best work.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----