Future of teamwork plugin

[Andreas Pakulat]

On 06.07.07 00:51:24, Andras Mantia wrote:
> Never say never. ;)

Hehe.

> 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."

Agreed. Still until now there's no agreement about wether to move it or
not.

> > > 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.

This is a distribution problem and not ours. How distributions package
the KDE module's is their "thing" and yes I do know some distro's suck
at this, thats just another reason to change the distribution - IMHO.

> 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.

And boost libraries add value for the user as well (granted not for
every user, but neither does svn support add value for every user): The
possibility to use teamwork. I'm not competent to judge wether teamwork
is possible with plain Qt, but according to its author its not.

> Boost libraries might add value for the coder, for the user it is just
> another library that he needs to install.

Thats wrong, IMHO. If Boost enables the coder to write code that
actually makes it possible to write this plugin then it also adds value
for the user.

> 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.

Oh, who said that? boost compile's totally fine with gcc4.2 and it also
works with gcc4.2 when itself is built with gcc 4.1. The problem I had
was with GNU Common C++, which uses a header (for providing mutexes
IIRC) from the standard gcc headers which doesn't exist in gcc 4.2. They
do have a proper check for that when you build common c++, however I
just switched my compiler here from the Debian default to gcc4.2 and
faced that problem. A rebuild of common c++ is all that was needed.

Also Common C++ will most probably (as it stands at the moment) be
replaced with plain Qt code. Converting it to CMake is just too much
work for too little gain here. And this will happen before the first
platform release.

Andreas

-- 
Tomorrow, this will be part of the unchangeable past but fortunately,
it can still be changed today.