On Tue, 2014-11-18 at 08:24 +0100, Thorsten Leemhuis wrote: > 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. Holding free drivers hostage to closed ones is obviously off the table; if I need to update X to get a feature into Fedora's radeon driver, and catalyst hasn't caught up yet, catalyst is going to lose that fight. But even the best free operating system is worthless if you can't use it, and the binary drivers do have actual features beyond the free ones that people do in fact depend on to get work done. So, while we continue to work on getting to feature parity, I don't want to be arbitrarily harsh to people who don't have a choice in the matter. It sounds like people are reasonably comfortable with a kernel-like update policy. If we run into that kind of ABI scenario with binary drivers, presumably the best course of action is to bring it up for discussion case by case and refer it to FESCO if it's especially contentious. Meanwhile, I've started assembling a crib sheet: https://fedoraproject.org/wiki/RebasingXserver I'll flesh that out more as we approach the first actual rebase like this, which if I had to guess would likely be early 2015. - ajax -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
