On Mon, 2015-05-11 at 11:14 -0400, Josh Boyer wrote: > On Mon, May 11, 2015 at 10:48 AM, Michael Catanzaro > <mcatanzaro@xxxxxxxxx> wrote: > > On Mon, 2015-05-11 at 09:32 -0400, Josh Boyer wrote: > > > I'm not sure if you meant to include the nVidia driver as one of > > > the > > > "technical issues", but it seems to be implied. While that might > > > be > > > the greatest driver in the world, there really isn't much we can > > > do > > > about it breaking from a technical perspective. It's > > > proprietary, so > > > we can't fix it to build against the latest kernel we're going to > > > ship > > > and we rely on nVidia to play catch up. > > > > I think we need to discuss locking the kernel to a single major > > version for the lifetime of each Fedora Workstation release. > > Otherwise, we're probably going to have to give up on nVidia users. > > There are a lot of lessons we've learned over the years working with > a > team of 3 people across up to 4 (i.e. Branched state) releases. One > of them is that freezing on a kernel version per release doesn't work > well. > > But I think you've overstated the problem and and over-"simplified" > with the suggested solution. The problem isn't that nVidia never > updates their driver. They do. And if we stuck with one kernel > version just because of them, we'd be sacrificing a number of other > users. > > The problem is the lag time between when Fedora rebases and when > nVidia and the 3rd party repos update to match the new kernel > version. > The most popular 3rd party repo already has a good understanding of > how and when Fedora rebases, but they need the newer kernel in place > in Fedora to build against once an updated driver is available. > Outside of building it within Fedora, I'm not sure there's much to be > done. This is somewhat mitigated by the fact that Fedora keeps 3 > kernels installed, so nVidia users still have working options. They > will get the update eventually. > One option here might be to attempt to coordinate with RPMFusion on releases. Perhaps we enforce a minimum time for the kernel in Bodhi (excepting security updates, perhaps) to give RPMFusion time to produce a matching kmod.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
