[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