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?
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!
CU
thl
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
