Yet another failed KDE release?

[Duncan]

Kevin Krammer posted on Fri, 22 Mar 2013 12:53:01 +0100 as excerpted:

>> Honestly, why can't KDE SC support seamless update from previous major
>> release? Is it too much work to rewrite config files whose format has
>> changed?
> 
> This is of course intended to happen, KDE software has had configuration
> and data modification tools for ages. My personal setup has been with me
> for over a decade now, rarely prompting me to reconfigure things.

FWIW, that's true here as well.  I've been running the same kde config, 
with /home copied over to new hardware (which on my workstation unlike my 
netbook, I upgrade a piece at a time so there's never a new computer, 
just a changed out drive, or max-change, a changed out cpu/mobo/memory/gpu 
all at the same time, as all the buses and formats had changed so to 
upgrade one I had to upgrade them all, but then it's the old hard drive 
installed in the new machine) as appropriate, since kde 2.x in late 2001, 
when I switched from MS to Linux.

Yes, that's the same base kde2 config now running kde4.  Every once in 
awhile, especially after the 2.x to 3.x upgrade and later the 3.x to 4.x 
upgrade, a few months after the upgrade I go thru and check file times, 
moving files to a backup location if the mtimes haven't bumped since the 
update, to see if they get recreated and/or whether they're I lose any 
customizations.

And yes, there's specific files (the infamous plasma-desktop-appletsrc 
being one of them) that I keep extra backups of and usually backup before 
any major changes, as I've learned the hard way how difficult it can be 
to find and edit out the bad bits on the more complex files if something 
does go wrong.

And yes, when I hit a problem, I know how to use the bisect method to 
narrow it down to a single config file if I have to (tho after doing it a 
few times and figuring out the way kde organizes its config, I found I 
could often pick the problem file purely by name, or at minimum, reduce 
it to a handful of files right away, so the bisect is now often only 3ish 
rounds max), and am used to doing just that, in kde config files or using 
git to bisect a kernel bug, either way.

But it really is possible to use the same basic config that long, even 
with heavy customizing, and I'm a case in point.

My problem isn't so much with that, it's with killing support for old 
versions before the new versions are sufficiently stable replacements, 
ESPECIALLY after promising support "as long as there are users!"  That 
triggered a drop of a lot of my former kde software choices with the bump 
to kde4, when kde was insisting that kde4 was stable and that they 
weren't supporting kde3 any longer, at the very SAME time they were 
saying on bugs "Oh, that's not ported to kde4 yet."  The story repeated 
with the akonadification of kdepim; I honestly DID try the akonadified 
kmail, but somewhere about the time it lost my 10th mail or so and I was 
trying to figure out whether it got caught in akonadi somewhere or was 
simply gone (after having to do much of the conversion manually in the 
first place because the automated process failed), I asked myself why I 
put up with it, why I couldn't just expect, AND HAVE, email that "just 
worked", that devs didn't needlessly change something that was working 
perfectly fine as it was, breaking it in the process.  (Ironically, I 
ended up on claws-mail, one of the "short list" of clients I had 
evaluated but eventually dropped for kmail, back when I originally 
switched from MS and OE.  It's still using the same mh-dir mail format it 
was back in 2001... and it still works.  Only unlike kmail, they didn't 
drop a well working solution in a chase for utopia.  Had I only chosen it 
back then...)

But, as I said earlier in the thread, that means I'm now running only the 
core kde desktop, with nearly all of my "mission critical" apps now non-
kde and to the extent possible, with semantic-desktop not just disabled 
at run-time, but without support for it even built at all.  Which means I 
don't have to worry about a broken kde killing my mail (for instance) any 
more.  Which means I'm now much freeer to run and /enjoy/ running the kde 
pre-releases. =:^)

And it also means if kde pulls the kde4 stunt again, since it's only the 
core kde desktop and a few games I'm running now, it'll be MUCH easier to 
drop it entirely, if I have to.

Fortunately, kde5 aka kde frameworks is supposed to be a much less 
disruptive upgrade, and it's going much more modular as well, so it's 
much less likely.  But THIS time I'm prepared, should it happen.  I won't 
be caught not viably being able to switch, again.

Which is even more proof that kde's not going to drop the ball that way 
again, because I'm actually prepared for it now, so of course it's not 
going to happen. =;^]

Of course there's the possible upcoming xorg -> wayland switch to worry 
about too.  That could really upset the Linux desktop environment status 
quo in all sorts of interesting ways and I think most of the leading DEs 
realize that.  But again, I'm much better prepared now, so regardless of 
how it turns out or what DE and apps I end up running on wayland and what 
kind of promises DEs and their devs make that they ultimately end up 
dropping like yesterday's dead fish in a malfunctioning refrigerator, I 
expect that switch to be far less personally disruptive than the kde3 -> 
kde4 upgrade was.  Which means to a certain extent I'll be able to sit 
back and enjoy the ride instead of sweating it out so badly this time, 
and I really am looking forward to that. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.