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

[Jaroslav Reznik]

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

Jaroslav