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

On Tuesday, January 31, 2017 12:00:07 PM MST kde-telepathy-request@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