Future of teamwork plugin
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
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