[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: A common roadmap
From:       "F () lk Brettschneider" <gigafalk () yahoo ! com>
Date:       2002-04-02 9:45:35
[Download RAW message or body]

John Firebaugh wrote:

> On Friday 29 March 2002 7:29, Roland Krause wrote:
> > --- Matthias H=F6lzer-Kl=FCpfel <mhk@kde.org> wrote:
> > > But you will have to pay this with a lot of extra work. I don't thi=
nk
> > > that you
> > > can not use gideon for anything, I rather think it is "almost there=
".
> >
> > No, it is not even 10% of the way. There are a few people here who us=
e
> > KDevelop on a daily base for payed work. Ask them. Gideon is nothing
> > more than a proof of concept. Of course that is only my opinion.
>
> I have to agree. Although I was encouraged by Matthias's recent work to=

> integrate QextMDI, I was once again disappointed upon trying out gideon=
=2E
> Roland is not exaggerating when he says gideon is not even 10% of the w=
ay.
>
> 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
>
> KDevelop 2.x is useable because it has polish. It has years of work by =
many
> many people implementing small but important features that when added
> together make a product that is comfortable to use. Things like: loadin=
g a
> project when it is imported from an existing directory, menu items to t=
oggle
> all the views and toolbars, properly working session and project restor=
ation,
> good looking and complete config dialogs, tons of documentation and hel=
p,
> configurable key bindings, well laid-out menus, working view management=
, nice
> icons, a better project import process, tons of usability fixes, etc, e=
tc. It
> is these small things, this polish, that we throw away by moving to gid=
eon,
> not to mention hundreds of thousands of user-hours of testing and thous=
ands
> of bugfixes. These things are not portable. Individually, they may be t=
rivial
> to implement, but the sheer number of them is overwhelming. Put simply,=
 it
> will take too long, and throw away too many peoples' hard work, to get =
gideon
> to the level that kdevelop 2 is now.
>
> My vote is to continue to refactor and clean up current KDEVELOP_2_BRAN=
CH
> code, always moving toward gideon's modular nature.
>
> later,
> John

The current situation reminds me of a neverending stalemate in a chess ga=
me. 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) bu=
t it
again divides both KDevelop parties. Maybe if we don't find a solution no=
w 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?

Ciao
F@lk

P.S.: Actually, the April joke I read on www.kdevelop.org isn't very funn=
y...



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


_______________________________________________
Kdevelop-devel mailing list
Kdevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]