Yet another failed KDE release?

[Duncan]

Kevin Krammer posted on Wed, 27 Mar 2013 21:54:28 +0100 as excerpted:

>> Which leaves amarok.  Amarok's kde3 -> kde4 conversion was for me a
>> microcosm of the larger kde3 -> kde4 debacle.  The devs tried switching
>> to mysql as akonadi was at the time, but in the process, they used
>> mysql functionality (something about a mysql library for use in other
>> apps, I've forgotten the details) that was completely broken on
>> amd64/x86_64 at the time, because as all libraries on amd64, the
>> library in question needed built with -fpic, but as that library was a
>> part of the larger mysql package and building the rest of it with -fpic
>> would have meant unacceptable slowdowns for the executables, nobody was
>> actually building it with -fpic.
> 
> This is strange, could that be a Gentoo artifact?
> MySQL is officially supporting in-process for some of its backends
> (usually MyISAM) and as far as I can tell worked well for most people I
> know (but those are all Debian users).

It wasn't a gentoo artifact, but due to gentoo being reasonably leading 
edge, gentoo (along with I suppose arch) was one of the first to hit it.

At the time mysql was having growing pains of its own, and this was one 
of them.  I wish I remember which library it was, but I believe it really 
hadn't been considered an external interface until just before this, and 
while amarok wasn't the first to use it, being as popular a kde app as it 
was, it was the first reasonably popular app to use it.  And I guess 
previous use had all been 32-bit, so it really hadn't mattered.  But the 
mysql build scripts weren't adding -fpic for that library's build yet, 
and the problem was so new people were figuring it all out in real time, 
so at first, the only alternative as to build the whole mysql package 
with -fpic on amd64.

But of course that slowed down the (non-library) executables, and a big 
part of mysql's appeal as a database has always been performance, so all 
the big data customers would have immediately protested at the loss of 
that few percent in performance, and the distros were thus stuck for a 
period of a few months with a broken-for-amarok mysql.

Meanwhile, amarok itself was behind kde4-core, and while kde4-core was 
busy telling users that kde3 was no longer supported, amarok and other kde 
non-core apps (at least k3b and kaffeine as well, that I was personally 
running at the time) had yet to release stable kde4 versions -- they had 
early alphas or betas out, but that was it.  So users had to choose 
between an unsupported kde3 core but stable kde apps, or a so-called 
stable kde4-core (which was really still alpha with 4.2, beta with 4.3), 
but deal with unstable pre-release non-core apps.

And I suppose the amarok devs thought it's only pre-release anyway, no 
big deal if amd64 users are shut out for a bit.  Except that only kde4 
was supported by kde-core by then, and I guess the amarok devs didn't 
consider the fact that they were locking out all their amd64 users that 
had already bitten the bullet (or in my case, were trying to bite it) and 
had switched to the only supported kde-core already.

Meanwhile, gentoo was still sort of supporting kde3 at the time, for 
stable anyway, but they'd already announced it EOLed because upstream kde 
wasn't supporting it any longer, thus signaling users like me to get our 
butts in gear and move to kde4 while the moving was good.  Except kde4 
was still horribly broken, both core and even more the non-core apps.

I expect amd64 archlinux users had a similar problem, because both gentoo 
and arch are rolling distros.  Standard non-rolling distros in many cases 
were still kde3 with their current stable release, and were working thru 
these sorts of problems for either the immediately following release or 
the one after that, depending on where they were in their cycle at the 
time.  That, or in a couple cases I guess the distros simply bit the 
bullet and switched to kde4 (exclusively) as well, since upstream had 
declared kde3 no longer supported, and what worked worked and what didn't 
didn't -- they were simply going with upstream.

Anyway, there really should have been kde3 support until at least the 
popular non-core kde-based apps were stable on kde4.  And as I've said, 
by (late) kde 4.5, pretty much everything (both kde core and non-core) 
was stabilized on kde4 that was going to be, so that's what /should/ have 
been 4.0 and would have been the minimum practical in ordered not to 
leave users in the gap.  Tho even that's pushing it, as many users aren't 
ready to switch with a normal x.0 release either, and giving them a year 
to switch would have meant supporting kde3 thru kde 4.7 or so.  But of 
course by then kdepim was going thru its betas, so it would have needed 
delayed further... until 4.9 or even the current 4.10.  Either that or 
kdepim shouldn't have been allowed that major switch in the "stable" 4.x 
series, and should have waited until 5.x to drop kmail1, etc, tho of 
course the akonadified kmail2 could have been developed along side, and 
people encouraged to switch when they were ready, since they'd have to do 
so by kde5 in any case.

But I do accept that sometimes volunteers simply won't be herded.  But in 
that case, the messaging was all wrong, given the promise.  But now I'm 
rehashing.

> It can be hard to tell from a developer perspective if something that is
> officially supported by an upstream dependency does not work under some
> circumstances and that some of your downstreams are triggern those.
> 
> Btw, isn't there a continuation of the Amarok version 1 project? I think
> it is called Clementine or something like that.

Yes.  Actually, I /think/ there might be /two/ such forks, clementine and 
something else.

However, by the time that came around, I guess many users had moved on.  
Certainly I had, /long/ before.  But I think even most stable users would 
have had to move on by the time clementine was ported, stable, and the 
news was out that it was an alternative, tho certainly amarok/kde4 would 
have been stable by then, just the feature set wouldn't have been the 
same.

>> I do sort of wish gwenview would implement audio file support, however,
>> and thus be a full media filemanager.  Media files are my biggest use
>> case for user-side/full-GUI file management, and gwenview handles
>> images and video well enough that I use it almost exclusively for them,
>> but it totally hides everything else, including audio-only files, which
>> are now one of only two things I use dolphin for.  The other is as a
>> trivial-case file browser, basically a file open dialog on steroids.
> 
> Interesting idea, have you checked if there is a wish item report for
> that?

I haven't.  The idea has only been gradually forming in my own head, as I 
watch what I choose to use as a file manager and under what 
circumstances.  I believe this was actually the first time I've expressed 
the fully formed wish-list item myself, solidifying the idea for me too, 
as I wrote about it (tho I've expressed hints at it before, just not the 
fully formed idea).

Thanks for the encouragement, however.  I'll consider submitting it.  
(But I just worked two full shifts with less than 8 hours between... and 
no sleep... so my mind rebells at even /thinking/ about doing it tonite.)

BTW, I did submit a couple superkaramba patches several kde versions 
ago.  But they seem to have fallen thru the cracks as I've not gotten a 
reply at all, to either one.  Which surprises me given that it's not just 
a wish, there's a patch attached for both, and if it's a rejection it'd 
be nice to at least know that.  Does superkaramba even have a maintainer, 
or was it ported to kde4 and abandoned to die?  What about for 
frameworks?  Since plasma supports superkaramba themes, I had assumed 
they'd take an interest in it if nobody else did, but... nothing.

Anyway, if you'd take a look and poke whoever, I'd certainly appreciate 
it.  The patches still apply fine here.  I know as I have them in the 
appropriate location here on gentoo (/etc/portage/patches/kde-base/
superkaramba/<name>.patch) so they get auto-applied to every superkaramba 
update I build, and the ebuild would error out if they failed to apply.

[Patch] Superkaramba cpu sensor missing wait-load
https://bugs.kde.org/show_bug.cgi?id=274906

[Patch] Superkaramba memory sensor missing buffers and cache
https://bugs.kde.org/show_bug.cgi?id=275070


-- 
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.