Yet another failed KDE release?

[Kevin Krammer]

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

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.
To make certain older version become unavailable would be a lot of work, 
requiring to remove tags, branches and time information from the repositories.
I consider it an inherent bonus of openly developed software that any version 
is available at any time.

Whether certain products are update to newer APIs mostly depends on human 
resources associated with the product.
Both as in availability (e.g. people switching to other areas, leaving the 
community, etc) and in decision making (e.g. joining efforts with a similar 
product's team, finding that newer technology has obsoleted a product, etc).

While this does of course impact ongoing maintenance, e.g. shifting from 
product creators to product distributors or deployers, it does usually not 
impact ongoing availability.
The latter usually not only in the form of markers in source code repositories 
but also in the form of archived release packages, etc.

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

One of the things that can easily be missed when not considering the 
surroundings of the "big picture" is that requirements for products of the 
same or similar category can be vastly different.

Akonadi is certainly a bit overengineered, also due to it being the second 
generation solution (second generation problem), but it does address needs and 
issues gathered over years of wide spread use.

For example, if we look at KMail, one can easily fall into the trap of 
thinking of it as just an program for writing and reading emails and thus 
compare it too closely with other products that do that but only that.

However, if one considers the additional requirements, it becomes often 
quickly obvious that other product's features for those requirements are 
either quite crude or not existant at all.

Lets for example take the basic requirement of enabling other programs to send 
email, e.g. need for sending out invitations to events in scheduling and 
calendaring applications.
While working on xdg-email it became often quite frustrating that email 
programs would either not have stable external interfaces (commandline, D-Bus 
or otherwise) or not even have them at all!

Another, often quite problematic use case, is providing access to the 
addressbook or being able to access an externally provided one.
A lot of programs fail to have accessors for external addressbooks, are only 
able to deal with their native one or are rather fragile regarding concurrent 
access (e.g. not having (proper) file locking or assuming in-memory state is 
equal to on-disk state, etc).

Even for KMail, which had those requirments covered for quite some time 
already, some choices on how to do them had massiv impact on the agility of 
the product, its maintainablity and so on.

The solution the involved developers devised deals with those requirements in 
an architecturally clean way. Unfortunately implementation of even the 
cleanest architecture and design can be difficult and appear to be complete 
and stable under test conditions because, e.g. some cases of data or 
configuration have just been hit yet.

Due to the availability of alternatives, including previous versions of the 
same product, these growing pains can often be mitigated for certain groups of 
users, e.g. those not needing any advanced features or those who can live with 
the quirks of previous versions.

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

Indeed. Frameworks 5, aside from its modularization work, will also improve 
the visibility of the distinction between different products. Discussions like 
this are a good example how difficult it still is for many people to see the 
how wide the range of products is, how unrelated certain products and their 
respective teams are to others, etc.

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

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.

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