Future of teamwork plugin

[Matt Rogers]

On Jul 3, 2007, at 4:11 PM, mchouinard wrote:

> On Tuesday 03 July 2007 16:43:02 Andreas Pakulat wrote:
>> 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
> I must admit I looked at some of the code because a few months ago
> I needed something like teamwork should do. so my idea was to take  
> part of
> this and port it to kdev3 or another editor ... but this code  
> scared me so
> much that we decided to simply cut and paste the editor windows in  
> a) IRC
> (private stuff), b) emails or c) IM ... it worked but was a pain ...
>
> the only future I can see for this plugin is a rewrite ...
> I don't know about it but maybe also a redesign ...
>
> (I don't want to start a flamewar or hurt anybody)
> Mathieu
>
> -- 

If you're scared of the code, it's because you don't know about the  
concepts it uses.  It's very advanced C++ and there's nothing wrong  
with that.
--
Matt