Yet another failed KDE release?

Kevin Krammer krammer at kde.org
Sun Mar 24 15:41:35 GMT 2013


On Sunday, 2013-03-24, Duncan wrote:
> Kevin Krammer posted on Sun, 24 Mar 2013 12:41:03 +0100 as excerpted:
> > On Friday, 2013-03-22, Duncan wrote:
> >> 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!"
> > 
> > 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.
> 
> For the record, this asegio post was the one I was referring to re the
> promise to support kde3 as long as there were users.
> 
> http://aseigo.blogspot.com/2008/01/talking-bluntly.html
> 
> A lot of folks including me took that as the promise it was, from someone
> in a position to make it, given his status at the time as president of
> the KDE foundation or whatever it/he 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 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".

> providing that support.  Yes, the Trinity folks stepped up, but there was
> no way to ensure they would, and indeed, kde3 users were left without
> reasonable support for quite some time before trinity got on its feet and
> was viable enough to do that support.

I think there are other entities that provide support and maintenance for 
software version that do not undergo any active development by the source 
community anymore. Not necessarily KDE software but I think there are even 
some which do that, i.e. I think SUSE and Red Hat do.

For some products such entities will even do active development, backporting 
and maintaining features added only to newer versions by the source.

> Of course that came on top of the hard fact that despite kde's insistence
> to the contrary, kde 4.3 was still alpha quality, not even beta.  I
> routinely run pre-release and know both the experience and definitions of
> alpha: critical features still missing, and beta: features generally
> implemented but sometimes broken, and with kde devs at the time of kde
> 4.3 still replying to bugs saying features weren't implemented in kde4
> yet, that's classic alpha.

I think the main problem here is lumping together different highly independent 
products into one term.
Most applications and libraries have been straight ports to Qt4, a lot even 
using Qt3 support classes and removing that dependency over many cycles.

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.

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.

> 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!  Had the whole <kde4.5 presented as full-quality-
> release thing not happened, I'd have had a lot more tolerance for
> problems as kmail worked thru them, but as the saying goes, fool me once,
> shame on you, fool me twice, shame on me, and I wasn't down with a repeat
> of THAT story!

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

This is especially frustrating because the granularity is way finer on the 
code contribution level, when sometimes only one or two individuals working on 
a specific program. There is often very little a programmer can do for another 
other than maybe tracking down a bug more deeply than the bug triagers or 
coming up with a potential fix which has still be validated and potentially be 
adjusted by the people who know the affected pieces.

> All that said, I do have this niggling worry about my over-reliance on
> the now deprecated gtk2.  I'm not /to/ worried as long as firefox isn't
> fully gtk3 ported yet, as that's a rather critical app, but there is that
> bit of cause for concern I see in the oncoming horizon.  I had mentioned
> wayland.  That's actually one of my concerns about it, as I'm running at
> least three gtk2 based apps I consider mission critical now, and until
> they're all either ported to gtk3 and gtk3 to wayland, or I know for sure
> that gtk2's going to be well supported on wayland, I /am/ a bit worried
> about the (near as I can tell) 18-36 months out timeframe.

I would assume that all the programs with active development communities will 
port or are already working on it.
On top of that I am basically certain that there will be at least one 
implementation of a mediator that can allow X11 applications to work in a 
Wayland context, probably more than one if they focus on different aspects.

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

> That's where my big wayland concerns are, that gtk2 and the like (tcl/tk
> comes to mind, tho IIRC I don't have it installed ATM and if I do I
> certainly don't have any "mission critical" apps on it... fltk...
> others...) may not be ported, and that various apps will die with x11 if
> wayland really takes off, as they'll remain unported from their dying
> toolkits.

While a change in display system will increase the advantage of the newer 
toolkits, the same situation would happen eventuelly anyway due to older 
toolkits no longer being maintained and eventually becoming to insecure to 
deploy by default.

> >> [The upcoming] xorg -> wayland [switch] could really upset the Linux
> >> desktop environment status quo in all sorts of interesting ways
> > 
> > My guess would be that only a small group of products will be affected,
> > mostly those related to the workspace category, maybe some system tools.
> > The vast majority of programs does not employ any X11 specific code and
> > should thus be mostly unaffected by a move away from it.
> > The main unforseeable issues would be hidden assumptions on system
> > behavior.
> 
> As I said above, I'm worried about non-leading-edge versions of toolkits
> and the apps that depend on them.  Definitely gtk2, but also tcl/tk, fltk,
> etc.  I'm afraid the non-leading-edge stuff may not be ported, and that
> the apps will die as a result.  Taking the gtk2-based claws-mail as an
> example, I mentioned in an earlier post how stable it was, and the irony
> of my being back to it after choosing kmail over it a decade ago.  It has
> a large enough userbase I don't see it going anywhere any time soon on
> its own, but it's only one among many gtk2 apps that will suffer if gtk2
> isn't wayland ported, and while kde4 (to be 5) and gnome3, and with them
> qt5 and gtk3, are certainly being ported, I know nothing about gtk2 or
> qt4 (let alone qt3 and kde3/trinity, tho I know they're working on a qt4
> port, but will it need to be qt5 and are they doing that?), let alone
> fltk, tcl/tk, etc.  There's a lot of apps around that "just work" without
> too much hassle now, that could be left behind if their toolkits don't
> make that wayland leap...

Qt4 could support wayland if somebody wanted to invest in that as its newest 
version is now also based on a plugin based platform abstraction the same way 
Qt5 is.

However, my best guess on continued viability is the almost certain 
availability of X11 mediators, most likely in the form of root-less Xservers.

> Of course they'll with a near-certainty still continue to work on xorg
> for a few years anyway, but once the general desktop moves to wayland,
> the X dependency gets moved to the "might not be installed for anything
> else" list, and suddenly the additional deps cost of running that old app
> go ***WAY*** up, which means fewer people run them, which means a bigger
> likelihood of an accumulation of serious bugs over time.

True, but as I said above that would most likely have happend anyway, i.e. due 
to using unmaintained libraries.

> Thanks for the discussion, Kevin.  Certainly we don't always agree, but
> I've definitely come to value your input rather highly whenever I see it,
> and you've certainly changed my thinking with a number of posts.  I know
> it can't be easy to deal with the negativity some posts seem to have,
> including my own at times, and I really do appreciate your continuing to
> post in spite of that.  As I said, you really /have/ changed my thinking
> at times, so it's not for naught, tho it may seem that way sometimes.

You're welcome!
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 :)

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20130324/40983f4a/attachment.sig>
-------------- next part --------------
___________________________________________________
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.


More information about the kde mailing list