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.
