[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-telepathy
Subject: Re: Telepathy KDE maintainership
From: Martin Klapetek <martin.klapetek () gmail ! com>
Date: 2017-02-01 15:44:38
Message-ID: CAPLgePr4uqJ6A0UPRBJFho3CcyMM9JB3pGEaX5Hj3kboc9zpOA () mail ! gmail ! com
[Download RAW message or body]
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
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, \
Jan 31, 2017 at 10:59 PM, James Daniel Smith <span dir="ltr"><<a \
href="mailto:smithjd15@gmail.com" \
target="_blank">smithjd15@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On Tuesday, January 31, 2017 12:00:07 PM \
MST <a href="mailto:kde-telepathy-request@kde.org">kde-telepathy-request@kde.org</a><br>
wrote:<br>
<span class="gmail-">> There *will* be bugs (you yourself have updated \
the RRs so many times<br> > already)<br>
<br>
</span>The new availability of Q_ENUM and the move away from Q_FOREACH did \
contribute<br> to the number of revisions. So did the new-style signals and \
slots, the lambda<br> functions allowing some things that were previously \
impossible. Lambda signals<br> and slots alone were worth their additional \
changes. A number of changes were<br> made that increased functionality \
after the code went up for review, this was<br> on top of reviewer's \
recommended improvements.<br></blockquote><div><br></div><div>That is what \
I'm saying. After reviews the functionality went up, it just \
keeps</div><div>going up. Bugs go up linearly with functionality. \
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> \
>highly complicated architecture<br> <br>
I don't think the Plugin implementation is that simple. Most of the \
complexity<br> is in the PluginQueue class, which has to dispatch many \
different signals for<br> the plugins, initiate changes to the plugins as \
well as provide a new presence<br> or status message value from the \
plugin's queue. The queues are mostly similar<br> but are fairly \
complex when the required logic is connected; preventing<br> multiple queue \
activations and clumped change events is half of the queue<br> signal \
logic. That class is also a DBus interface, potentially complicating<br> \
the code in classes that interface it. It doesn't change the type of \
wrapped<br> export variables.<br></blockquote><div><br></div><div>There \
should be no plugin queue. I have specifically told you many, \
many</div><div>times in your RRs that the mpris thing should just die. \
There should be</div><div>a simple auto-away and lock-screen integration, \
that's it. No plugins, no</div><div>queues, no extra added complexity. \
Nothing like that is needed.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><span class="gmail-"> >there will be \
*nobody* to look after those bugs<br> <br>
</span>The code is working and closes an unusually large number of bugs or \
wishes,<br> and effectively finishes the status handling portion of KTp \
feature-wise. The<br> plugin-related bugs weren't widely complained \
about or reported, but still the<br> existing shortcomings were addressed, \
the code was augmented in some areas<br> that led to better and cleaner \
separation, some (arguably important) missed<br> functionality was \
implemented, and more KTp features can now be worked \
on.<br></blockquote><div><br></div><div>Every code works on developer's \
machine. There will be bugs and someone</div><div>will have to take care of \
them. That's simply a history-supported fact, not</div><div>a random \
statement pulled out of the blue. There is currently noone \
taking</div><div>care of bugs. That is also a fact.</div><div \
class="gmail_quote"><br></div>Given all that, my position still stands. KDE \
Telepathy does not need this</div><div class="gmail_quote">extreme \
complexity, what it needs is reducing the code and features so</div><div \
class="gmail_quote">that it becomes manageable for a single maintainer. And \
then it needs that</div><div class="gmail_quote">single dedicated \
maintainer that will be able to take care of the whole</div><div \
class="gmail_quote">project, which is already super huge.</div><div \
class="gmail_quote"><br></div><div class="gmail_quote">Cheers<br \
clear="all"><div><div class="gmail_signature"><div dir="ltr"><div \
dir="ltr"><div><span \
style="color:rgb(102,102,102)">--</span></div><div><span \
style="color:rgb(102,102,102)">Martin Klapetek</span> \
</div></div></div></div></div></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic