On Thursday 04 March 2010 17:33:20 Orion Poplawski wrote: > On 03/04/2010 07:18 AM, Rahul Sundaram wrote: > > On 03/04/2010 07:27 PM, Kevin Kofler wrote: > >> That said, IMHO the best solution is still to have this stuff in the > >> official updates. But it's true that the kind of issues some users are > >> having with KDE 4.4 are unfortunate. This particular Akonadi issue > >> hasn't shown up during testing or it would have been considered a > >> blocker. > > > > The whole point is that you will invariably find such breakage when > > pushing updates like this *after* the release and this is precisely why > > there are huge discussions on this topic and sooner you realize that no > > matter how careful you are you only increase the risks by doing such > > updates mid-release the better off we are towards a reasonable level of > > compromise > > > > Rahul > > Kevin/KDE SIG - > > I would also like you to consider that simply changing the behavior of a > system, while not technically a bug or regression, can be frustrating to > a lot of users (I have reports of different looking panels, different > task bar graphics behavior). Especially to sysadmins like myself who > manage multiple users' systems and have to deal with and explain to the > users all of the changes that happen. It is much easier for me to say - > when is a good time to upgrade to Fn? and the user can prepare for > changes and time it to not coincide with other deadlines, etc. > > And please, just assume like Rahul says that there *will* be > bugs/regressions that aren't found in testing for major updates like > this, and take that into consideration. > > I'm sure some (most?) of my frustration needs to be directed with KDE > upstream and their cavalier attitude towards preserving settings and > data during updates, but I also really don't want to have to deal with > this any more than I have to. That's the problem - it's just postponed to upgrade from update - you can choose one hell from 1. break update, 2. break upgrade. None of this should happen. > (Off to track down changes in XRANDR behavior with 4.4.0 ....) -- Jaroslav Řezník <jreznik@xxxxxxxxxx> Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
