Yet another failed KDE release?

[dE .]

On Sun, Mar 24, 2013 at 5:11 PM, Kevin Krammer <krammer at kde.org> wrote:

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde/attachments/20130329/a5c12b3d/attachment.htm>
-------------- 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.