A common roadmap

Matthias Hölzer-Klüpfel mhk at kde.org
Tue Apr 2 18:48:04 UTC 2002


On Tuesday 02 April 2002 11:45, gigafalk at yahoo.com wrote:

> > Perhaps some of you have read Joel Spolsky's articles about rewriting
> > software. If not, I'd encourage you to do so. In particular, these two:
> >
> > Things you should never do, Part I:
> > http://www.joelonsoftware.com/articles/fog0000000069.html
> >
> > What to do instead:
> > http://www.joelonsoftware.com/articles/fog0000000348.html

Hm, I am not sure he is completely right outside the close-source world, but 
his arguments are usefull sometimes.

They would be especilly usefull if the alleged, but imho not correct, 
assumption would hold, that gideon is only 10% of what KDevelop2 is right 
now. For my day-to-day work, which means being able to do development in C++, 
C and Java, gideon seems a lot closer than KDevelop2.


> The current situation reminds me of a neverending stalemate in a chess
> game. We discussed about the suggestion of porting the Gideon plugins over
> to the stable core of KDevelop2.2 and meanwhile MHK worked and improved the
> Gideon core by adding the QextMDI feature. A pretty nice piece of work (I
> salute MHK) but it again divides both KDevelop parties. Maybe if we don't
> find a solution now a cvs split of the team and of the cvs modules (in
> cvs-module gideon, kdevelop and kdevbase) is better for the whole KDevelop
> project?

Well, some here say that gideon is missing the KTextEditor interface, so I 
added them. The next argument was it was missing the QextMdi interface, so I 
added it. Now you say, this is deepening the split.

Could we have a simple poll? How many people would say that they would never 
work on gideon, whatever it's technical features would be? I have the feeling 
that would make the whole situation a bit clearer.

I think splitting the effort is a waste. If the team decides to stay with the 
KDevelop2 line, I think we should simply discontinue the gideon development. 
I don't have any interest working on a project that noone else is interested 
in. If you all think this is the faster way to something usefull for non-C++ 
developers, maybe I should just wait a year and have a look at it again.


Bye,
Matthias.





More information about the KDevelop-devel mailing list