Future of teamwork plugin

[mchouinard]

On Tuesday 03 July 2007 21:10:06 Matt Rogers wrote:
> 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
>
I understand those concept, I might not use them but the point was like I say 
in a later email is when you have to spend more than 15 to 30 minutes (and 
this is way too much time) to understand what a method does, it mean from a
maintenance point of view that there is something wrong, that's all ...
it's ok with me if david plan to be around for 5 years to support and 
maintaint this code ;)
Mathieu


-- 
Mal: "Kaylee's been missing you something fierce."