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:So what is the solution you are suggesting?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 graphicsearly 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).
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?
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!