Future of teamwork plugin

[Andras Mantia]

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:
> http://techbase.kde.org/Policies/SVN_Commit_Policy
> and in particular
> http://techbase.kde.org/Policies/SVN_Commit_Policy#Don.27t_commit_if_
>other_developers_disagree

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 
works):
"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 
now: discussing.
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
> wrong.

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


-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org