On 03/08/2010 08:26 AM, Rex Dieter wrote:
One more call for discussion around another proposal that came out of
FUDCon
Toronto. Short version of this is that we'd consider slowing down updates a
step, esp for the second half of a fedora release's lifetime, and to limit
kde 4.x-type upgrades to at most 1 per release.
http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Whatever we decide, increasing our transparency by documenting our update
practices will hopefully help shape everyone''s plans and expectations. As
it is, seems these vary wildly.
-- Rex
Hi,
In paper, well in this times, in the wiki conservative updates seems a
great idea, in practice not so much.
I'm a Fedora user, because, the latest or almost latest version of Linux
(unix/cli programs) and KDE latest,
maybe change
"to limit kde 4.x-type upgrades to at most 1 per release"
to
"stop kde 4.x-type upgrades one month before the Release of next Fedora
version."
because the former suppose which Fedora will not have a long development
cycle and kde cannot have two (major versions) shorter ones.
but if the above scenario occurs, by example:
- One month from Fedora Release, KDE release a major version.
- Four months later KDE release a new major version
- The next Fedora has delays
- result Fedora current cannot upgrade to the latest kde because the
guidelines say so.
having not the latest KDE in the latest Fedora Release, well that will
be a point where I will consider migrate to another distribution.
considering the following scenario:
backporting is a con, not a benefit, kde is really huge to try to
backporting fixes, well in the sense laid in the proposal and that will
break the "releases close to the upstream ships"
if you have a stable kde in Fedora N-1 why take the risk of backporting
fixes not done by upstream (besides security fixes), I mean risk of
introducing new code, source of potentially new bugs.
in my opinion leave kde in Fedora N-1, alone besides major bugs happening,
Not which I didn't found bugs or breaking something in kde with my
computers, but all were fixables.
If I need working with the computer with a timeline, I don't update
until having time to dedicate, because the risk of breakage.
So as a Fedora user the current policy fits my needs, I only hope which
the new one meets them too.
Gabriel
P.D. I'm not like conservative aproach because sometimes that is
translate if something don't work right at release shipping time and
only is fixed in major version of software, the software aren't updated
case in point:
xorg intel driver in F11 version 7.X -random freezes with desktop
effects enabled
solution by upstream update to version 8.X of the drivers
solution by policy desactivate the desktop effects the 7.X drivers stays
in F11
my solution rebuilding the 8.X rpm from rawhide under mock, after that I
have KDE running with desktop effects enabled in F11 without crashes.
P.D.-2 I have many more problems with PulseAudio, sometimes PA works
beautifully , and sometimes wants to have a rest :) , and I did'nt see
yet the proposal to bring back ALSA and dmix meanwhile PulseAudio is
developed to a working state, and this isn't against PulseAudio itself
I use it, but if a new update policy is developed I doubt PA meets the
standard to release.