RFC: xserver update strategy in F21+

[Josh Boyer]

On Tue, Nov 18, 2014 at 2:24 AM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> Lo!
>
> Adam Jackson wrote on 17.11.2014 20:06:
>>
>> With that in mind, I ask for feedback on how we'd actually like that to
>> work.  The kernel rebase policy seems like a pretty reasonable model:
>> F21 would stay on 1.16.x until there's an upstream 1.17.1 release, and
>> (if F20 were to be affected by this policy) F20 would wait until 1.17.1
>> had been tested in F21.
>>
>> One thing we might have to play by ear is the interaction with binary
>> drivers.  The nvidia legacy driver, for instance, does not always have
>> builds available for arbitrarily new servers, which means updating the X
>> server might change you to an nvidia driver that no longer supports your
>> hardware.  Depending on how severe that cutoff is, it might be cause to
>> pin a particular Fedora release at a given server version.  I don't
>> think this is presently a problem, but it could be in the future.
>
> The same problem can and did arise with the kernel updates Fedora does.
> Fglrx/catalyst in the past more than once got broken when Fedora shipped
> a new major version (3.x -> 3.(x+1)) as a regular update, because the
> flgrx/catalyst kernel module the flgrx/catalyst driver for X.org relies
> on was incompatible with the new kernel. Sometimes (but not always!)
> there were patches to work around that (and yes, they often got
> integrated into RPM Fusion packages).
>
> But in the end Fedora and its kernel maintainers didn't care. Which

It's not that we don't care.  That can come off like we're gleefully
breaking people's machines for fun, which is certainly not the case.
However, as Adam said, we aren't going to hold the kernel package
hostage to closed drivers.  Unlike XServer, people have parallel
installed kernels and can boot into the older one while they wait for
their proprietary driver to update it really isn't as dire as people
make the situation sound.

josh