On Tue, Jan 31, 2017 at 10:59 PM, James Daniel Smith <[email protected]> wrote:
> On Tuesday, January 31, 2017 12:00:07 PM MST [email protected] > 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
