Future of teamwork plugin
amantia at kde.org
Thu Jul 5 21:51:24 UTC 2007
Never say never. ;)
On Friday 06 July 2007, Andreas Pakulat wrote:
> 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 it:
> and in particular
Of course it is not easy to remember everything (especially as before
techbase information was not that easy to find), but I read shortly
before posting the previous way and I didn't change my opinion that
what you wrote is not a general policy (and not how the KDE project
"If there are disagreements over code changes, these should be resolved
by discussing them on the mailing lists or in private, not by forcing
code on others by simply committing the changes to SVN."
No word about 2 who disagree, and this is eactly what we are doing right
In other places of the very same document you can read that it is not a
generic rule what's written there:
"Respect the policies of application and library maintainers, and
consult with them before making large changes."
> > 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
What I forsee is that the user wants to install Quanta in a distribution
and will suddenly need to install boost, even if Quanta is not using.
Through the dependency of Quanta on kdevplatform, which depends on
teamwork, which depends on boost. And I certainly hate such cases, and
I know it happens, as I saw them in many cases that I had to install
software I don't care about, just because some stupid dependency. If
teamwork it in a separate module from the start, this is avoided.
And no, depending on subversion (even libraries), konsole or other
runtime programs doesn't hurt that much and I mostly don't care.
Subversion libraries add value for the user: subversion support. Boost
libraries might add value for the coder, for the user it is just
another library that he needs to install. And the issue with different
versions of boost and that scary comment that boost doesn't compile
with gcc 4.2, didn't make me happier. And makes me wonder, if it
compiles with compilers that KDE officially support (gcc 3.3.x and over
And sure this is also a matter of taste.
Harddrive and internet might be cheap these days, but I hate disk and
bandwith wasting and I'm not going to forget that just a few moths ago
how I struggled on a 6GB hard driver or with a 15KB/s net connection.
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
More information about the KDevelop-devel