Thoughts on Fedora Server lifecycle

[Josh Boyer]

On Fri, Nov 1, 2013 at 4:27 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>>> 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.

Anaconda farms out as much as it can to the underlying base packages.
Unless they're changing how they develop their installer, that means
it's going to rely on the underlying packages in F24, which at that
point would be in major flux.  I'm not sure it's feasible to apply
that to an older stable base.  If it was, we wouldn't be having a lot
of the troubles we do today with current Fedora.  The main problem is
relying on that moving base while at the same time trying not to
duplicate all the functionality in anaconda itself.

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.

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

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.

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

Hey, you posted this on Friday not me ;).

josh