Yet another failed KDE release?
krammer at kde.org
Sun Mar 24 11:41:03 GMT 2013
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
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.
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
-------------- next part --------------
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde