KDevelop 3.0.1

[Alexander Dymo]

It is time to clarify my opinion :)

> What do you think to reorganize our cvs repository?
> 
> 1) rename gideon to kdevelop
Strongly agree.

> 2) remove cvspart
Veto unless we provide a solution to perform cvs operations on 
KDE < 3.2 without cervisia installed.
Currently cvspart is the only solution that works without cervisia.
We can leave it for the 3.0 release and maybe remove after the release.
Importing cervisia into KDevelop source tree is not the best solution
especially when we are closing to the release.

> 3) add the support in autoconf/automake stuff for enable/disable
> languages
Strongly agree. We should also disable some languages by a default.

> 4) Move things around in the repository:
> a) move the unmatained plugins to 3rdpart
Agree.

> b) create languages/c++/*, languages/java/*, ...
>           languages/ <language>/appwizard (  move the appwizard 
> templates in language support plugins )
>           languages/<language>/filecreate  ( do the same thing for 
> filecreate templates )
>           languages/<language>/support
>           languages/<language>/project (!?)
>           languages/<language>/plugins/compiler
>           languages/<language>/plugins/importer

I don't know if it is so necessary. But I have no serious objection
against it.
But I'd prefer to not create following:
           languages/<language>/project 
Project managers should not be language specific.
I hope I will have enough time to complete generic project so we
will be able to remove scriptingproject, adaproject, pascalproject 
and haskellproject.

Instead we can create
projectmanagers/
projectmanagers/autoproject
projectmanagers/trollproject
projectmanagers/genericproject
projectmanagers/genericproject/plugins
projectmanagers/customproject

> c)Create a documentation browser
>          parts/doctreeview/html
>           parts/doctreeview/pdf
>           parts/doctreeview/man
>           parts/doctreeview/info
> With plugins:
>           plugins/docs/qt
>           plugins/docs/doxygen
>           plugins/docs/kdoc
>           plugins/docs/devhelp
>           plugins/docs/toc
>           plugins/docs/docbook

This makes no sence because doctreeview is monolithic.
It should be made plugin based, but again, that is for 3.1 release.
It is too late to rework the code in 3.0. We can introduce more bugs
without a chance to solve them in time.

> d) Create a version control part
>          parts/vcs
> 
> With plugins:
>          plugins/vcs/cvs
>          plugins/vcs/svn
>          plugins/vcs/perforce
>          plugins/vcs/codesafe
Agree. But I'd prefer
vcs
vcs/cvspart
vcs/cvsservice
vcs/subversion
vcs/perforce
vcs/clearcase
At this time that parts aren't plugins.


And the last question. Where shall we put other parts?
Shall we leave them in /parts directory?

-- 
Alexander Dymo
Ukrainian State Maritime Technical University, IT Department