On Thu, Sep 01, 2011 at 01:59:59PM -0400, Josh Boyer wrote:
On Thu, Sep 01, 2011 at 12:22:07PM -0500, Jason L Tibbitts III
> >>>>> "JB" == Josh Boyer <jwboyer(a)redhat.com>
> JB> F14:
> JB> The two most likely options are staying on 2.6.35.x, or moving to
> JB> 2.6.40 as F15 did.
> Has anyone made 2.6.40 packages install on F14? Unfortunately the F15
> kernel package needs some other stuff, and due to all of the systemd
> changes I'm not sure it would boot OK.
No. And I wouldn't recommend force installing the F15 versions either.
If (and it's a big if) we move F14 to 2.6.40, we need to update a number
of userspace packages first, including microcode_ctl so people with
various AMD systems can actually boot...
> I would happily deploy a 2.6.40 on my remaining F14 machines even if I
> had to pull it from an external repo.
We need to discuss this a bit more, but we could potentially setup a
koper with the various bits.
We thought this over a bit last friday afternoon and I thought I would
reply so that everyone knew what the decision for F14 is.
The creation of a separate repo that contains 2.6.40 for F14 is
certainly possible, but at the moment we aren't sure it's worth doing.
The major concern is that it becomes a timesink in both creation and
support. We know of a certain set of userspace that needs to be
updated to work with 2.6.40, but that isn't an all inclusive list.
Assuming F16 is released in November, F14 will go EOL in December which
leaves just 3-4 months of support remaining. The frequency of new bug
reports on F14 has been fairly low over the past month or so, likely due
to people moving to F15 and the 2.6.35.x kernel being a known quantity.
So for F14 we are going to remain on 2.6.35.x until EOL and focus mostly
on security fixes and low hanging fruit bug fixes. Those with major
issues will be encouraged to upgrade to F15.
Going forward, we're going to get back into rebasing more frequently
during a release and that should help avoid being stuck on older