Future of teamwork plugin

Andreas Pakulat apaku at gmx.de
Thu Jul 5 21:25:16 UTC 2007

On 05.07.07 23:57:01, Andras Mantia wrote:
> On Thursday 05 July 2007, Andreas Pakulat wrote:
> > Sorry I think I'm missing something. KDE's svn commit policy
> > explicitly states that there should be no changes done that have been
> > objected to. 
> I am around for about 5 years and never heard about such policy. :) To 
> be more concerte, there might be such policy for parts of KDE, but the 
> KDE svn is so huge, with lot of projects and so on, there simply cannot 
> be such a global policy there. 

Then you didn't read the SVN Commit policy, its been there since at
least 1 year (back then on developer.kde.org), thats when I first read
and in particular

> 3. Because it is big compared to other plugins from the platform. (1.4MB 
> source for teamwork, 600KB for the rest of 9 plugins).

Thats partly because teamwork is mostly feature-complete (afaik), while
the others are not. the projectmanagerview for example still lacks
plenty of functionality.

> 4. Because might not be that useful for the generic audience (e.g single 
> developers, developers working with vcs systems). Having for those who 
> need accessbile in an easy way is something I support very much, though 
> as I have no problem with this teamwork idea!

Teamwork does _not_ replace a version control system, it complements it.
Think about how often people paste diff's into a pastebin and somebody
else applies it locally to check. This is eased by teamwork, also it
provides integrated messaging and all that without the need for a
specially setup server.

> 5. Because it depends on boost and I don't like to have Quanta depend on 
> it.

Sorry, I don't understand this.

a) teamwork is a plugin, so quanta doesn't depend on it or boost at all
b) teamwork is optional, you can disable it by doing cmake
-DBUILD_teamwork=off (unless the kde4 macro is broken)

Following you're thinking Quanta also depends on subversion libs, cvs
and konsole (the latter two during runtime), which is completely wrong.

> 6. Because it has a copy of libdiff2.

That will most probably be removed, because at least parts of that will
become part of the vcs library.

> You can agree or disagree with me, that will not make a difference with 
> the fact that this is how I see kdevplatform & teamwork now.

I totally agree about the code part (which is why I left it out),
however the other points I don't agree that much.


Love is in the offing.  Be affectionate to one who adores you.

More information about the KDevelop-devel mailing list