Yet another failed KDE release?

[Duncan]

Kevin Krammer posted on Sun, 24 Mar 2013 16:41:35 +0100 as excerpted:

> On Sunday, 2013-03-24, Duncan wrote:
>> Kevin Krammer posted on Sun, 24 Mar 2013 12:41:03 +0100 as excerpted:
>> > 
>> > Well, the 3 series was actively released about one and a half year
>> > into the 4 series and continues to be available up to today.
>> 
>> http://aseigo.blogspot.com/2008/01/talking-bluntly.html
>> 
>> A lot of folks including me took that as the promise it was[.]
>> KDE's reneging on that very publicly made promise lost them
>> the trust of a LOT of users and admins who were depending on
>> KDE to keep its word.
> 
> Well, KDE e.V. has no say of what contributors of KDE do, it was
> specifically designed that way to falling into the trap of steering by
> committee.  No individual in a community of peers can make promises on
> behalf of other indivuals, unless the first individual happens to be
> the employer of the second or has some other form of contract.

I did say that I'm aware of the difficulty of steering volunteers, who 
after all can simply take their donated time and donate it elsewhere.

And in fact that was what I guess kubuntu and some others were (rightly, 
it turned out) predicting, the reason they didn't do an LTS at the time, 
because they didn't believe the upstream support would actually be there.

In fact, I believe the above linked post was in part a direct reply and 
counter to such concerns.

How then could-it/did-it so overreach, without equally public disavowal, 
if indeed it was a promise he had no standing to make, so apparently 
directly addressing the concerns of the community that there WOULDN'T be 
such support, promising there would be, from someone apparently in a 
position to make that promise?

> I would interpret such a statement as an assumption based on
> expectations of that time, e.g. that users would have switched to the
> new stack as some point or moved to products provided by other
> "vendors".

I guess so.  But a lot of users including me were looking for answers at 
the time, and took that as the answer they were looking for.  Live and 
learn, I guess.  FWIW, that would appear to be why the gnome3 
alternatives sprang up so quickly when it jumped the shark as well -- 
they too had learned from the kde3 -> kde4 debacle, and how trinity 
stepped up, but too late to actually make a difference for many.

So the community appears to have learned its painful lesson from both kde 
and gnome, and come away older and wiser for it.  It's a much different 
place now, and I don't think it could happen again -- the community would 
step in a lot faster this time, as it did with the gnome3 alternatives 
when they tried it, and at a rather smaller scale, as I personally did 
with my switch to claws-mail from kmail when it tried it.

> I think the main problem here is lumping together different highly
> independent products into one term.

Thanks for continuing to emphasize that, Kevin.  It's certainly going to 
be interesting to see how the kde frameworks 5 thing plays out, 
especially given that qt5 is going the much more modular route at exactly 
the same time, with most components of each becoming optional, only 
installed when a specific app needs them.

It sounds real good and I'm definitely looking forward to it, but there's 
both the challenge of actually getting there, and probably some not yet 
fully perceived down sides as well.  But it'll definitely be interesting, 
and I really AM looking forward to it, at this point anyway believing 
it'll be a dramatic improvement on what we have at present.

> There were a couple of newly developed programs but they were almost
> always components of the workspace product.
> I am currently not aware of any application which dropped features
> during the porting, but I can obviously not know all applications and
> all their features.

For the most part it wasn't so much dropping features, as in way too 
visible and important cases, dropping the SINGLE "feature", reliability, 
that everybody wants and uses, while ADDING features that were nice 
enough, but added bloat and weren't particularly useful without the core 
reliability that got dropped somewhere amongst all those changes.

But there were a few feature drops as well.  The biggest two projects I 
can name here aren't part of kde-core, but they're headline kde apps and 
thus very important: kaffeine, and amarok.

AFAIK kaffeine for kde4 simply took too long to mature, and in the mean 
time, it simply didn't have the power features that people used it for in 
the kde3 era, instead of the many other media player alternatives out 
there.  Features like frame-by-frame advance and incremental playback 
speed.  These are advanced features that simply aren't available in the 
default level offerings, kde3 OR kde4, that had people using kaffeine for 
kde3 instead of the lower featured alternatives in the first place.

I /think/ it actually got there by now, but I don't know, as I long since 
moved on to smplayer (and am now running smplayer2) and vlc, both of 
which have these missing features.

Vlc, meanwhile, is an interesting case in itself, as the real reason I 
have it installed (as opposed to only smplayer/smplayer2) is due to the 
phonon-vlc backend.  I don't have gstreamer installed at all, due to it 
simply not working all that well years ago when I last tried it (it's 
probably just fine these days, but I've simply not needed it installed, 
as gstreamer's a pretty heavy ecosystem and there have always been 
alternatives to bringing it ALL in as a dependency, phonon-vlc vs. phonon-
streamer being a perfect example), and when it became clear that phonon-
xine simply wasn't cutting it, I needed an alternative and the two 
available were phonon-vlc and phonon-gstreamer, and as I didn't have 
either one installed and wasn't interested in playing the whole gstreamer 
game again if I could avoid it, vlc it was, especially since I knew of 
its media-player fame and this gave me the excuse I needed to try it out.

Otherwise I'd have probably not installed vlc either, as its deps are 
pretty hefty too, and unlike the xine, mplayer and gstreamer ecosystems, 
save for phonon-vlc, vlc doesn't seem to have much of a surrounding 
ecosystem of its own.  But the mediaplayer AND phonon-backend angles 
combined took vlc over the threshold despite its rather heavy deps, so 
it's installed now and I tend to use it and smplayer2 more or less 
interchangeably.  That was handy in at least one case on my netbook, as 
smplayer quit working (it'd freeze the system) there at one point, I 
believe due to its use of graphics accel functions that were buggy on 
that generation Intel graphics driver.  But vlc continued to work just 
fine. =:^)  But on my workstation (with its radeon graphics and the 
freedomware drivers, which never had that problem), I favor smplayer (now 
smplayer2), as I can't quite say why, but I just seem to be more 
comfortable with it.

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.

So by choosing to use this mysql library amarok effectively decided they 
were going to break for 100% of their amd64 users until the problem was 
fixed upstream and in the distros their users were using.  At minimum, 
that demonstrates a seriously callous disregard for the needs of this 
major and growing user segment, as I said, basically the same disregard 
the entire kde4 project was demonstrating for users at the time, by 
insisting kde4 was ready and dropping support for the actually working 
kde3, while kde4 was still in actuality very very alpha quality.

With amd64 being my primary platform, despite the fact that I knew the 
problem and being a gentooer I could have simply added -fpic to my build 
flags for mysql myself, I was already unhappy with where amarok was 
headed, and that was simply the last straw -- I looked elsewhere and 
ended up with a FAR lighter (even with the multiple front-ends I built 
for it) mpd, music player daemon.  Which as a bonus brought a new feature 
I could actually use with it, the fact that I could now play music at the 
command line without X even running, and could continue to play music 
uninterrupted thru kde/X restarts, etc, something I'd been missing with 
amarok.

And the plethora of mpd frontends I installed, including two (qtmpc and 
qmpdclient, the former discovered and installed later) for qt4, 
originally one for qt3, which I still had installed as I worked thru the 
kde3/kde4 upgrade issues, the mpc CLI frontend, and two curses-based semi-
guis (ncmpc and ncmpcpp), STILL was far FAR lighter than amarok and its 
deps, including ruby, which was installed only for amarok.  (FWIW there's 
additional mpd frontends available for gtk2/3 and web-based access, among 
others, but I didn't need those.)

Meanwhile, amarok had dropped support for the kde3 version's miniplayer 
and with it the winamp skins it supported, which I definitely used, and 
had dropped the mini-visualizer as well, which I also used.  At the same 
time, they were expanding support for their database backed interface 
with the mysql integration, but I didn't need or use the database backed 
interface features.  And they did this cute little minibrowser thing, 
which I didn't need or use (I HAVE a browser, thank-you, and prefer 
opening links in it, as it's a full-featured browser).  And IIRC they 
improved and further integrated lyrics lookup and covers support, neither 
of which I needed or used.

So it was a case of adding all sorts of features I had no use for while 
at the same time killing features I definitely used, and the breakage on 
amd64 was simply the last straw in an already sad situation, here.

But I really never had been comfortable with amarok even in kde3, because 
of its incredibly high deps requirement, and incredibly poor even then 
ratio of features I actually used to non-optional features along with the 
deps they brought in, that it forced.  So it was at best a "bad marriage" 
to begin with, and I didn't consider it a /terrible/ loss.  Certainly far 
less so than the larger kde3 -> kde4 debacle, or the later akonadified 
kmail thing.

I DID miss amarok's full-size projectM visualizations for awhile, but 
eventually I discovered that vlc has them when I installed it for phonon-
vlc.  And for me mpd's X-independence and plethora of frontends was about 
an equal tradeoff, feature-wise, which made mpd the FAR superior choice 
for me, given its FAR lower deps requirements.  Also, it's apparently 
possible to hookup projectM based visualizations to mpd's fifo output, 
but I've not yet done the research to figure out how, and with vlc's 
handling projectM based visualizations, it's a relatively low priority 
for me now, so I might not ever get to it but that doesn't bother me too 
much.

> The closest thing I can come up with is a change in feature set in
> Konqueror's file manager "personality" due to also using the engine
> developed for Dolphin.
> Given the alternative of not having the file manager "personality"
> anymore it was probably still the right choice.
> 
> However, doing most of my file management on the shell makes me a bad
> judge on that matter.

You and me both. mc for the win! =:^)

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.

If gwenview had a checkbox for audio file support as it does for video 
file support it'd cover the media angle entirely.  And if it further had 
a toolbar button and/or hotkey toggle to show all files, not just media 
files, it'd cover the file-open-dialog-on-steroids case as well, and I 
could probably uninstall dolphin as I recently uninstalled konqueror 
(because it's no longer a reasonable full-use browser if it ever was, I 
use firefox now, and the few cases I use a full GUI browser for are 
covered by dolphin and gwenview).

And that wouldn't change gwenview's primary images use case or non-
optional deps at all, since the audio file thing would be a checkbox much 
like the existing video file checkbox, and the show-all-files thing would 
be a button/hotkey toggle that could remain off by default.  Any 
additional deps pulled in could be optional as well, but they'd certainly 
be no worse than the deps for dolphin, so if it meant people could make 
gwenview their default file manager (already a kcontrol option) and get 
rid of dolphin entirely, it'd be a net plus.

>> Actually, that's why I jumped off of akonadified kmail so fast.  I saw
>> the whole early kde4 thing happening all over again.  Only this time I
>> knew there were alternatives and I make the personal executive decision
>> to take one of them!
> 
> Yes, one of the things that needs to be and hopefully will be addressed
> by the split on the next version transition is the invisibility of
> project boundaries.
> There is often very little or sometimes even no overlap at all between
> the groups of people working on certain products.

Again, thanks for continuing to point this out.  It's a message with 
value, but it takes some time to sink in, apparently for all the reasons 
you explain (which I agree with).

> This distinction of different topci groups is often assumed and
> understood for non-coding related contributions, e.g. translators for
> language A not being involved in anyway with translations of language B
> other than potentially collaborating on improving source strings or
> working on common tools and procedures.
> 
> For some unknown reason this does not seem to be the case for the code
> contributors, i.e. people assuming that a set of contributors to one
> product somehow having influence or even control about any work going on
> for a different product.
> 
> It is probably easier to consider for the example of translations
> because everyone is aware of their own limits when it comes to multiple
> languages, while for non-coders the work of coders will look like being
> the same thing.

Thank you very much for the translations analogy!  Please put it on your 
list to use again when making this point, as it REALLY EFFECTIVELY 
brought home the point to me! =:^)


[On the topic of wayland porting, X mediation layer "emulation" approach.]

> The potential for that approach has been demonstrated by platforms that
> have never used X11 as their primary display system, e.g. several highly
> committed vendors producing Xservers for Windows.
> 
> Another analogy could be the existence of a multitude of terminal
> emulators for all those programs that did not get an "X11 port".

Both valid analogies.  Thanks.

[meta on negativity]

> If negativity ever gets out of hand I will simply switch to a news based
> reading approach and use scoring rules to only see discussions that have
> interesting participants :)

More or less what I'm doing now with my lists (including this one) via 
gmane... which actually might have been why you mentioned it I guess.  

Except that I'm interested in all sorts of stuff, and tend to give anyone 
but direct spammers (and occasionally people who insist on repeatedly 
posting in HTML, despite requests) the benefit of the doubt, even if 
they're overly negative.

So I don't use scoring that much, except as I said to killfile the 
spammers.  But for sure I'm a big booster of the lists as newsgroups 
thing, and thus of gmane.  For similar reasons I now run two separate 
instances of claws-mail, one for mail, the other for my rss/atom feeds, 
and I don't do irc, which along with running pan for news and handling 
feeds as news, means the only thing my mail client handles is mail, not 
news, not feeds, not lists, not instant messaging or IRC, not 
appointments or calenders or..., only (non-list) mail. =:^)

Meanwhile, I run multiple (pan) news instances as well.  One for my text 
groups, one for binaries, and one for temporary test group subscriptions 
and general unsubscribed group browsing.

Sounds a bit like that old Unix philosophy of a dedicated tool for each 
job, let each tool do one thing and do it well, but with easy 
interoperation and data exchange between them, doesn't it? =:^)

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