Since the modular X repackaging in FC5, we have limited X server updates such that the ABI does not change. F20 shipped with xserver 1.14.4, for example, so we might update it to 1.14.7 but not to 1.15.0. With the reduced driver set in F21 it's now much more reasonable to push updates to older releases as well. 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. This would also want some coordination with the various desktop environments; the version of KDE in F21 might have latent bugs only exposed by switching to F22's X, for example. I have a reasonable idea of how to test Gnome for that kind of thing, but for the others I'd need some pointers. So what do we think? Good idea? Bad idea? Other things to watch for?

IMHO, we should not let proprietary drivers hold us hostage that way. We do not and should not support them. We don't even ship them. So we should just upgrade X if the software we ship is ready for it. If some proprietary driver breaks, its users get to keep the pieces.

However, isn't it possible to have both. I'm not familiar with the proprietary drivers other than knowing that the NVidia one is available through rpmfusion. (Out of the many varieties of laptops I've installed Fedora on (at least 30 different models from various manufacturers), I've only had one that required the NVidia driver.) If the proprietary driver has a strong dependency on a certain X version, won't that just stop the X server from being upgraded? In that case, everyone using the open drivers can upgrade and the others will just not get the new X server until they have new drivers available. I expect this doesn't work if you compile from source though. Are there many people that do that?

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.

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

On Mon, Nov 17, 2014 at 8:06 PM, Adam Jackson <ajax(a)redhat.com&gt; wrote: > Since the modular X repackaging in FC5, we have limited X server updates > such that the ABI does not change. F20 shipped with xserver 1.14.4, for > example, so we might update it to 1.14.7 but not to 1.15.0. With the > reduced driver set in F21 it's now much more reasonable to push updates > to older releases as well. > > 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. So now that we have 1.17.1 ... has any decision been made yet?