On Sun, Mar 24, 2013 at 5:11 PM, Kevin Krammer <krammer@xxxxxxx> wrote:
See, we all agree with the fact that KDE SC is a complicated project and it's a good design; for starters Akonadi is the only piece of software proving the likes of MS exchange. But the project doesn't have enough developers to satisfy the release needs, especially if it's @ 6 months.
The developers are less+they are contributers+KDE SC is HUGE and complicated, but still 6 months?
On the other hand, look at Xfce. They're hesitant to add basic features like Thunar search, tabbed browsing, cause they say the don't have enough developers. On top of that look at their super slow release cycles (-bugfixes).
As a result there exists nothing more stable than Xfce.
You can even look at Gnome. They test their major releases for full 6 months, and release a beta every month.
On Friday, 2013-03-22, Duncan wrote:Well, the 3 series was actively released about one and a half year into the 4
> 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."
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.
One of the things that can easily be missed when not considering the
> 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...)
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.
Indeed. Frameworks 5, aside from its modularization work, will also improve
> 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.
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.
My guess would be that only a small group of products will be affected, mostly
> 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.
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
See, we all agree with the fact that KDE SC is a complicated project and it's a good design; for starters Akonadi is the only piece of software proving the likes of MS exchange. But the project doesn't have enough developers to satisfy the release needs, especially if it's @ 6 months.
The developers are less+they are contributers+KDE SC is HUGE and complicated, but still 6 months?
On the other hand, look at Xfce. They're hesitant to add basic features like Thunar search, tabbed browsing, cause they say the don't have enough developers. On top of that look at their super slow release cycles (-bugfixes).
As a result there exists nothing more stable than Xfce.
You can even look at Gnome. They test their major releases for full 6 months, and release a beta every month.
___________________________________________________ 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.
