some closure on the xorg updates issue

[dragoran]

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
reboots
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!
>
+1
> CU
> thl
>