Telepathy KDE maintainership

[Martin Klapetek]

On Tue, Jan 31, 2017 at 10:59 PM, James Daniel Smith <smithjd15 at gmail.com>
wrote:

> On Tuesday, January 31, 2017 12:00:07 PM MST kde-telepathy-request at kde.org
> wrote:
> > There *will* be bugs (you yourself have updated the RRs so many times
> > already)
>
> The new availability of Q_ENUM and the move away from Q_FOREACH did
> contribute
> to the number of revisions. So did the new-style signals and slots, the
> lambda
> functions allowing some things that were previously impossible. Lambda
> signals
> and slots alone were worth their additional changes. A number of changes
> were
> made that increased functionality after the code went up for review, this
> was
> on top of reviewer's recommended improvements.
>

That is what I'm saying. After reviews the functionality went up, it just
keeps
going up. Bugs go up linearly with functionality.


> >highly complicated architecture
>
> I don't think the Plugin implementation is that simple. Most of the
> complexity
> is in the PluginQueue class, which has to dispatch many different signals
> for
> the plugins, initiate changes to the plugins as well as provide a new
> presence
> or status message value from the plugin's queue. The queues are mostly
> similar
> but are fairly complex when the required logic is connected; preventing
> multiple queue activations and clumped change events is half of the queue
> signal logic. That class is also a DBus interface, potentially complicating
> the code in classes that interface it. It doesn't change the type of
> wrapped
> export variables.
>

There should be no plugin queue. I have specifically told you many, many
times in your RRs that the mpris thing should just die. There should be
a simple auto-away and lock-screen integration, that's it. No plugins, no
queues, no extra added complexity. Nothing like that is needed.


> >there will be *nobody* to look after those bugs
>
> The code is working and closes an unusually large number of bugs or wishes,
> and effectively finishes the status handling portion of KTp feature-wise.
> The
> plugin-related bugs weren't widely complained about or reported, but still
> the
> existing shortcomings were addressed, the code was augmented in some areas
> that led to better and cleaner separation, some (arguably important) missed
> functionality was implemented, and more KTp features can now be worked on.
>

Every code works on developer's machine. There will be bugs and someone
will have to take care of them. That's simply a history-supported fact, not
a random statement pulled out of the blue. There is currently noone taking
care of bugs. That is also a fact.

Given all that, my position still stands. KDE Telepathy does not need this
extreme complexity, what it needs is reducing the code and features so
that it becomes manageable for a single maintainer. And then it needs that
single dedicated maintainer that will be able to take care of the whole
project, which is already super huge.

Cheers
--
Martin Klapetek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20170201/f9b4e55b/attachment.html>