Future of teamwork plugin

[Andreas Pakulat]

On 03.07.07 21:58:43, David Nolden wrote:
> Am Dienstag, 3. Juli 2007 18:56:36 schrieb Alexander Dymo:
> > On 7/3/07, Andras Mantia <amantia at kde.org> wrote:
> > > Even if we abstract from the code content itself, if you admit that you
> > > have no time to work on and as it was not really tested for the simple
> > > case that KDevelop4 is pretty much in unusable state, and as KDevelop4
> > > will continue to move forward, this is enough to say that your code
> > > shouldn't stay *now* in kdevplatform.
> >
> > I'd like to stress the "now" part here. Once you have some time
> > working on it and polishing its code we can move it back because
> > basically everybody agrees teamwork is cool.
> 
> Teamwork is in a mainly working, and even stable(whereby I mean not crashing) 

stable != not crashing, but I think you're aware of that.

> state now. It mainly lacks integration into kdevelop(which was not possible 
> when creating it, kdevelop has the ability to show context-menus since only a 
> few months), some polishing of the user-interface, and disabling a few parts.
> 
> That's all not too big issues.
> 
> The question is: Why is it important to remove a plugin that nothing is going 
> to depend on NOW?

It is dead code and I think one of the issues we wanted to avoid in
KDevelop4 is carrying dead code around. What is so bad about moving the
plugin to a (quite popular) place in playground?

> It is quite probable that I will find time to fix the issues in a few months, 
> as long as the plugin stays in a working state.

Its not in a working state right now, except on your and my system. That
is it doesn't compile against boost 1.33.1. Its also in a non-working
state on at least 1 platform other than linux and yes IMHO that counts
wether KDE4/win32 happens for 4.0 or for 4.1.

> It is a lot less probable when kdevelop-teamwork is resting in some 
> playground-corner and kdevplatform is evolving without it.

Uhm, thats wrong. Nobody will maintain it in its current state except
you and I doubt it really matters for you where it lives. If you care
enough about it and have the time you can fix it inside the platform as
well as outside of it.

> Personally I've got the feeling that to some people there's nothing more 
> important than the count of krazy-issues, which imo is a little ridiculous. 

Come on, just because I told you that your email address in copyright
statements won't work? Are you serious? Its not about wether krazy
points out 1, 10 or 100 issues on the teamwork plugin (currently there
only false positives there), its about complex code that is going to be
unmaintained for the upcoming months. Obviously nobody showing
interest in maintaining the code due to its complexity. IMHO this
dis-qualifies the teamwork code to be a plugin in the base module for
KDevelop and Quanta. And on top of that, you never raised a discussion
about including teamwork plugin in KDevelop (the move to the platform
was natural as it is a general purpose plugin) and I'm not the only one
who was confused by that.

> Of course you can reduce that count by removing 30tsloc.

Removing teamwork will not reduce the krazy count. I already fixed most
of the issues and what I saw along the way does really scare me, And I'm
not even close to be as picky as kdelibs developers (see the "flamewars"
with Matthew Whoelke, Thomas Zander and others on kde-core-devel).
Right, its a plugin that doesn't need to keep BC, but it should keep at
least a certain level of code-quality, which IMHO it does not at the
moment.

Andreas

-- 
The whole world is a tuxedo and you are a pair of brown shoes.
		-- George Gobel