[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: some closure on the xorg updates issue

Thorsten Leemhuis wrote:
Rahul schrieb:
Thorsten Leemhuis wrote:
Agreed for things like gnome 2.x -> 2.(x+2), but hardware support is a special case IMHO. Consider this hypothetical example:

early april 20xx: FCx get releases with Xorg y.z
mid april 20xx: Xorg y.(z+1) gets released with new drivers
end april 20xx: Intel releases Chipset G1015 with integrated graphics
early may 20xx: Intel releases updated drivers for G1015 that require Xorg y.(z+1)

Those buying a Mainboard with G1015 need a solution then. They don't want to wait 5 month until the next proper FC release. Or 2 month for a beta (and most people don't want to run a beta).
So what is the solution you are suggesting?

Well, there probably is no solution that can be set is stone completely. We need to discuss some things on a case by case basis. But I'd suggest this rough scheme:

Kernel, X.org and other userland drivers (like hpijs, gutenprint, sane,...) should normally be updated "quickly" (*1) to the latest version in the latest stable Fedora release if the new version improves hardware support. In cases like X.org 7.1, where the update might break important non-Fedora stuff (like the proprietary drivers from nvidia), we need to discuss how to proceed. Maybe setting up a special repo that has the newer X would be the proper solution *until* the non-Fedora stuff is fixed.

(*1) = read quickly as: Push the stuff to rawhide. Wait one week. If everything looks okay push it to updates-testing for a week. After that week move to updates proper if no big breakage showed up in between.

Does that sound sane?

in case for a kernel there is no problem if the kernel does not work its easy to boot the older one .. but in case of X its different.
we need 2 things done to get this fixed:
1) X should fall back to vesa (or better autodetected driver) if the driver selected in xorg.conf does not support the abi version
2) yum/pirut needs a downgrade option
then things could be like this:
user starts pup and updates X
X detects older driver (ABI) selected
reverts to nv (or vesa)
user notices that 3d accel is gone look at the logfile notice a error that says driver does not
work with this X version
(or atleast ask in fedora-list/nvidia forums)
user runs pirput and downgrade X
user goes to nvidia forums and complain
nvidia releases a new driver
user updates X and is happy
now this could end like this:
user updates X
no X only console (don't know what to do)
move to other distro or even worse back to windows.....

The balance we are trying to reach here is avoid regressions while being a fast moving distribution.

Bugs will always happen due to version updates while other bugs get fixed due to the new version. Take a look at the frequent kernel updates in Fedora Core. Changing to this release scheme (e.g. always update to the latest kernel from kernel.org in the latest Fedora Release) was IMHO one of the best things we ever did. davej, many thx for your work!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]