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 might be the right thing to do for X as well, because companies then learn that they need to keep track of ongoing development and users notice some of the risks these driver bear. CU knurd -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
