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?
- ajax
On 17 November 2014 20:06, Adam Jackson ajax@redhat.com 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.
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?
Looks like the policy for RHEL. Right now my RHEL 6.x systems have X 1.15 from official updates, which is even newer than the Fedora 20 X server. If it can be done for even older RHEL releases that are supposed to keep ABI stability I don't know why it could not be done for Fedora.
Maybe pushing not-the-very latest X.org server in stable releases would prevent disruption with binary drivers, just like what is happening for RHEL. Just my 2c.
Regards, --Simone
Adam Jackson wrote:
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.
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.
Kevin Kofler
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
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.
I agree to some extent, but in the real world, there are a significant number of Fedora users that use such third-party software. Breaking it with no consideration will end up pushing users to other distributions, which shouldn't be done without forethought.
On 11/17/2014 12:54 PM, Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
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.
I agree to some extent, but in the real world, there are a significant number of Fedora users that use such third-party software. Breaking it with no consideration will end up pushing users to other distributions, which shouldn't be done without forethought.
My opinion is strongly in line with Kevin, but Chris has a good point. 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?
On Mon, Nov 17, 2014 at 4:50 PM, Samuel Sieb wrote:
My opinion is strongly in line with Kevin, but Chris has a good point.
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?
1) proprietary drivers depend on the kernel 2) yes people do build from source but indirectly via the akmod system used in RPM Fusion
Whether we should care about those users depends on whether we care about users or just our own repositories. We have in the past done new releases that broke the proprietary drivers and that's somewhat unavoidable but breaking them in an update might too problematic. I would suggest avoiding that if we can.
Rahul
On 11/17/2014 04:16 PM, Rahul Sundaram wrote:
- proprietary drivers depend on the kernel
Aren't there two parts, the kernel driver and the X driver? From the earlier discussion, it sounds like some part depends on the X server ABI.
- yes people do build from source but indirectly via the akmod system
used in RPM Fusion
Those should be able to control the dependencies. Wouldn't that work?
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
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
On Tue, Nov 18, 2014 at 2:24 AM, Thorsten Leemhuis fedora@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
On Mon, Nov 17, 2014 at 8:06 PM, Adam Jackson ajax@redhat.com 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?
On Fri, 2015-02-13 at 14:36 +0100, drago01 wrote:
On Mon, Nov 17, 2014 at 8:06 PM, Adam Jackson ajax@redhat.com 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?
1.17.1 was built for F22 all of two days ago, I'm not sure that counts as "tested in" yet. But yes, I would expect us to update F21 to 1.17.1 in a week or two.
- ajax
-
Adam Jackson -
Chris Adams -
drago01 -
Josh Boyer -
Kevin Kofler -
Rahul Sundaram -
Samuel Sieb -
Simone Caronni -
Thorsten Leemhuis