Future of teamwork plugin

[David Nolden]

Am Donnerstag, 5. Juli 2007 23:51:24 schrieb Andras Mantia:
> 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
> IIRC).
>  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.
>
> Andras

I think this is far too much worries in such an early stage of development! 
The main reason why I want teamwork to stay where it is, is so I can easily 
develop it, and maybe some time others too.

We can decide any time to make it separate, but I simply don't see even the 
slightest profit in doing that NOW, just because I cannot care about it. 
Moving it away NOW only makes it harder for me to maintain it, because I am 
working on C++ support, and will be working on it after SOC, and being able 
to work on both without additional effort will make maintaining both easier.

It will also make it easier for others to try teamwork out, and teamwork WILL 
create a lot of additional value for everyone who is working on a team, which 
should be 90% of all open-source developers.

It may even provide more value than each of cvs-support and svn-support etc., 
because in real world developers use many different version-control systems. 
But all of them are able to profit from the teamwork-plugin.

The boost libraries of course do give value to the user:
Teamwork

Where's the difference to subversion-libraries there? You could also implement 
subversion-support without using subversion-libraries, so by your definition 
the developer is the one who profits from using the libs, because he gets a 
nicer interface.

greetings, David