[Fedora Base Design WG] Committee FESCO approved, next steps

[Stephen Gallagher]

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

On 11/06/2013 11:09 AM, Phil Knirsch wrote:
> On 11/06/2013 04:46 PM, Stephen Gallagher wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 11/06/2013 09:57 AM, Bruno Wolff III wrote:
>>> On Wed, Nov 06, 2013 at 15:38:10 +0100, Phil Knirsch 
>>> <pknirsch at redhat.com> wrote:
>>>> 
>>>> But i do like the idea of well "Overlap" releases? Where most
>>>> of the release would stay stable in a sense of API/ABI and we
>>>> could still bring out a newer release.
>>> 
>>> Since we have a system where multiple kernel types can be 
>>> installed, maybe we could use that to have a latest stable
>>> kernel package and a latest long term support kernel package.
>>> This will take more kernel team resources and may have some
>>> issues if the graphics drivers devs want to take advantage of a
>>> new feature that isn't going to be back ported to stable.
>> 
>> Alternately, maybe this is one of the cases where we leave it to 
>> RHEL/CentOS to cover. For really long-term kernel support, those 
>> groups are much better equipped to resource it than the Fedora
>> kernel team.
> 
> Hm, so would the Fedora Server products base their releases then
> on CentOS instead? Otherwise, if due to resource constraints the
> Base

No, please don't take that from what I said. I actually mean pretty
much the opposite. In my vision, the Fedora Server should be CLEARLY
the feeder channel for RHEL and CentOS server offerings (in that
order; Fedora Server is the feeder for RHEL server which is the feeder
for CentOS server).

I merely meant that if a user absolutely needs a stabilized and
*supported* (in the commercial or near-commercial sense) kernel, that
they should be looking at products intended for that purpose. The
Fedora Server should certainly be useful, but not on the same ten-year
cycle. In general, if we settled on eighteen to twenty-four months of
updates, I think that would strike a usable balance.


> products can't have a longer life cycle then say, 1 year or so,
> how would the Server products from Fedora be able to provide
> longer lifecycles on top of that? Would they support the Base they
> are using themselves? Who would do that?

This is still being discussed. Please see the thread "Thoughts on
Fedora Server lifecycle"[1]

My plan would be for the server to have a stabilized release every
eighteen months and after that an updates roll-up every six months
thereafter. These updates should be more tightly controlled than the
classic Fedora firehose (possibly limited to security and data-loss
issues). Kernel will probably get a pass to just rebase though. If you
want to discuss this, please do so on the thread I mentioned above.
I'd prefer not to split the discussion.


> 
> As at the end of the day, as Bruno already mentioned in his answer,
> # of releases per year and lifetime of one product don't scale
> well. They actually scale quadratic, which is even worse. So we'll
> have to find some common ground and ideas on how we can manage to
> support both fast moving products e.g. like Cloud or potentially
> Workstation vs. slower moving and longer living ones like i expect
> Server.
> 

That's why in my lifecycle discussions I'm aiming to time update
releases and preview releases alongside the Base releases. That way
they should stay closely aligned.


> And don't take this as an attack please, i just want to ensure
> everyone is on the same page regarding our finite resources and how
> we can most efficiently use them and find a solution that will work
> for all involved WGs and products.
> 

No attack


> Thanks & regards, Phil
> 


[1]
https://lists.fedoraproject.org/pipermail/server/2013-November/000369.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ6escACgkQeiVVYja6o6Mn3wCgn9JiY51rv1eX0RHKMusWbCGS
dBAAniKXnndc08CKlPS+5rBPof5VRqSc
=7ZSc
-----END PGP SIGNATURE-----