Why people are not switching to Fedora

[Stephen Gallagher]

On Mon, 2015-05-11 at 11:14 -0400, Josh Boyer wrote:
> On Mon, May 11, 2015 at 10:48 AM, Michael Catanzaro
> <mcatanzaro at gnome.org> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20150512/6aa3085b/attachment.sig>