From kde-telepathy Wed Feb 01 15:44:38 2017 From: Martin Klapetek Date: Wed, 01 Feb 2017 15:44:38 +0000 To: kde-telepathy Subject: Re: Telepathy KDE maintainership Message-Id: X-MARC-Message: https://marc.info/?l=kde-telepathy&m=148596392502882 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--001a114d2df2f56402054779ee0f" --001a114d2df2f56402054779ee0f Content-Type: text/plain; charset=UTF-8 On Tue, Jan 31, 2017 at 10:59 PM, James Daniel Smith 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 --001a114d2df2f56402054779ee0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, 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 lam= bda
functions allowing some things that were previously impossible. Lambda sign= als
and slots alone were worth their additional changes. A number of changes we= re
made that increased functionality after the code went up for review, this w= as
on top of reviewer's recommended improvements.
That is what I'm saying. After reviews the functionality we= nt up, it just keeps
going up. Bugs go up linearly with functiona= lity.=C2=A0
=C2=A0
>highly complicated architecture

I don't think the Plugin implementation is that simple. Most of the com= plexity
is in the PluginQueue class, which has to dispatch many different signals f= or
the plugins, initiate changes to the plugins as well as provide a new prese= nce
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 wr= apped
export variables.

There should be no pl= ugin queue. I have specifically told you many, many
times in your= RRs that the mpris thing should just die. There should be
a simp= le auto-away and lock-screen integration, that's it. No plugins, no
queues, no extra added complexity. Nothing like that is needed.
=C2=A0
>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. T= he
plugin-related bugs weren't widely complained about or reported, but st= ill the
existing shortcomings were addressed, the code was augmented in some areas<= br> that led to better and cleaner separation, some (arguably important) missed=
functionality was implemented, and more KTp features can now be worked on.<= br>

Every code works on developer's mac= hine. There will be bugs and someone
will have to take care of th= em. That's simply a history-supported fact, not
a random stat= ement pulled out of the blue. There is currently noone taking
car= e of bugs. That is also a fact.

G= iven all that, my position still stands. KDE Telepathy does not need this
extreme complexity, what it needs is reducin= g 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 sup= er huge.

Cheers
--=
Martin Klapetek=C2= =A0
--001a114d2df2f56402054779ee0f--