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

[Stephen Gallagher]

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

On 11/06/2013 12:31 PM, Jaroslav Reznik wrote:
> ----- Original Message -----
>> -----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.
> 
> Well, even for 18-24 months of updates you first need buy-in from 
> packagers (and probably our sponsor too as it was rejected several
> times). And with that conflict - resources to backport stuff or do
> updates (that's the reason why we have so many updates - no
> resources to backport fixes, more hope that upstream fixed it and
> it's regression free :D).
> 
> So we need some balance - time, quality, rebases vs backports. And
> we can't have all of them :).

Well, the difference from previous approaches is that I'm not talking
about supporting additional branches too. For the "preview" branch,
every six month release until the stable one is immediately obsoleted
upon the release of the new one. So you can either be on the 6-month
front-lines or you can stay on the 18-24-month LTM version. This keeps
our contributors only concerned with two release branches at a time,
just as they do now.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ6gwIACgkQeiVVYja6o6NT4QCdFlfBwe3yx4pby2YkrzfO7Ggv
3CwAn1Jh5FrQT/OF1pooLhbT6cmPrzpl
=faEw
-----END PGP SIGNATURE-----