ANNOUNCE: New KDevelop Design

Ansley, Michael Michael.Ansley at intec.co.za
Fri Oct 1 09:26:01 BST 1999


Save yourself (left hand on forehead, right hand on back of head), save
yourself.

Right, I think this presents a challenge.  It has occurred to me that Cat
(Mr. Climov is a little too formal for these discussions) may come from an
environment that is new to open source, and although embracing the concept,
still carries some mental baggage.  The traditional concepts of ownership
and control are difficult to leave behind.  I know, I went through the same
'withdrawal' when I started working in an open environment.  The idea that
someone else is in charge is a little unnerving at first.  Now I know the
first response from most people is: but when you buy software, someone else
is in charge.  That's true, but for some reason, you don't notice it quite
as much as when you start working with open source.  You start looking for
some stability, and you know that you can create it.  I think that what Cat
is proposing comes from an instinctive reaction to have something that is
internally controlled.  This will change over time, as he and his colleagues
spend more time working with a project like (y)ours.

The challenge here is to grow him, and the company that he works for, into a
true open source mindset.  The reason for this is simple.  It can be
mutually beneficial, because the KDevelop project suddenly has access to
further resources, commercial resources, which have a direct interest in the
project.  This can be a powerful ally.  Ex unitate vires (Unity is strength)

Of course, maybe I'm way off the mark, and Cat is just trying to take over
the project, but I'm an eternal optimist, especially when it comes to
people.

MikeA

>> -----Original Message-----
>> From: Ralf Nolden [mailto:Ralf.Nolden at post.rwth-aachen.de]
>> Sent: Thursday, September 30, 1999 2:13 PM
>> To: kdevelop at barney.cs.uni-potsdam.de
>> Subject: Re: ANNOUNCE: New KDevelop Design
>> 
>> 
>> Hi again,
>> 
>> I'm back !!!!
>> 
>> ;-) 
>> 
>> Now, to this subject I will give my 2 cents as a KDevelop
>> core-developer:
>> 
>> a) Sandy is a man.
>> b) he is not dead or unavailable, just busy working on the new
>> plugin-structure/modularization.
>> c) he has received Mr. Climov's mail about the "New design"
>> d) we have talked about it
>> e) we are not yet finished to find an agreement because of the simple
>> reason that we don't know where this thing comes from
>> f) I just answered Sandy to reply on the mailinglist to 
>> clear out some
>> things
>> g) I wanted to answer yesterday already, but had no time ;-(
>> h) here comes my statement :
>> 
>> A)
>> As far as the questions of Mr. Climov go regarding a "New design" for
>> KDevelop, we have the following situation:
>> 
>> The KDevelop Team as a team of independent individuals, but 
>> organized in
>> the development of the KDevelop IDE, started and still runs 
>> the KDevelop
>> IDE project. This will not change and the project will continue. 
>> 
>> If developers that use KDevelop take the codebase and change 
>> it to adapt
>> new things like the debugger, this is fine with each core-developer,
>> including myself. Making the patches available is nice and serves
>> everyone, but it is not part of the official development 
>> state which is
>> found by consent of the core-developers in regular intervals where we
>> meet and discuss directions. The stability of the IDE 
>> requires this and
>> prevents code-changes that could be hard to reverse in the future.
>> 
>> The current state of the development is that we're fixing the 1.0
>> version, so that it is almost bug-free considering the desired state.
>> Therefore not many features are added officially, because we want a
>> rock-stable 1.0.  In parallel, we're porting to KDE 2 and 
>> have to take
>> the pace for the changes in the KDELIbs API to offer 
>> developers the 1.0
>> in a KDE 2 version for their development. In this, we're making good
>> progress.
>> 
>> New features get implemented now as well. We're testing the MDI
>> interface, the dockwidget interface and so on, but have to 
>> take care of
>> the 1.0 and HEAD branch to keep them in sync. Also Sandy 
>> promised to fix
>> a bug in the project management of HEAD and will have 
>> finished the new
>> plugin API for KDevelop plug-ins by this weekend.
>> 
>> KOM/OP architecture functionality will also be added, but is 
>> delayed for
>> some weeks until HEAD kdelibs have a code-freeze and the 
>> status of the
>> CORBA architecture is cleared, this will add IDL support to 
>> KDevelop and
>> a new Appwizard that will also generate KOffice and KOM/OP 
>> frame apps.
>> The current HEAD version works, including the browser and the
>> mini-template, the normal and qt template are not yet ported.
>> 
>> Now to the points Mr. Climov mentioned:
>> > 
>> > Considering the following facts:
>> > a. Actual KDevelop has poor modularization; it lacks in (true)
>> > multi-language and plugin support.
>> -KDevelop is definitely one of the KDE applications that 
>> have the best
>> API interface, completely modularized and separated into 
>> classes. Even
>> in such a complex codebase, the class hierarchy makes 
>> additions easy. 
>> 
>> -Furthermore, KDevelop's internationalization is one of the best
>> regarding the huge mass of documentation to be translated. There are
>> some dialogs that will be redesigned anyway, therefore we delayed
>> implementing geometry management for those that will be 
>> changed; the new
>> ones will have full geometry management support (if that is what is
>> meant by lack of multi-language support)
>> 
>> -The plugin support will be available this weekend (see above)
>> 
>> 
>> 
>> > b. The original team is working a lot on improving and bug 
>> solving on the
>> > actual design/implementation. I doubt that they will have 
>> time for a
>> > re-design soon (that would mean that for a long period of 
>> time KDevelop will
>> > mark no visible progress).
>> - I doubt that there is really a need of redesign. The 
>> codebase that is
>> there is actually the best one could wish to have for a 
>> functional IDE.
>> 
>> - we will have time. The last three month have been bug-fixing and a
>> waiting for KDE 1.1.2 with which KDevelop should have been 
>> brought out.
>> We canceled this plan shortly before the release, so we have 
>> more time
>> for bug-fixing and don't set ourselves under pressure.
>> 
>> - we already have visible progress regarding the porting to KDE 2. I
>> changed the templates to the new autoconf, just the code 
>> needs adaption,
>> and the documentation browser works again except for a bug when
>> displaying KDevelop's own documentation.
>> 
>> 
>> > c. Such a great tool as KDevelop is MUST have better design and
>> > modularization.
>> > We don't want (just) another IDE, we just want to improve 
>> KDevelop. We want
>> > to (re)use the code that was already written. 
>> 
>> To my mind this statement suggests, that your firm located 
>> in romania is
>> trying to take KDevelop out of the hands of the 
>> core-developers. If you
>> were a "normal" developer that would come to us and say: "hey, I can
>> program and I want to help improve things" like Jonas did, 
>> we have a new
>> core-developer and that's ok. In this case, I think I am right that I
>> suspect some really black clouds coming. 
>> The GPL allows code-reuse, so noone and nothing can prevent your
>> corporation to take the KDevelop code and change it like 
>> Corel changed
>> KDE code for their distribution. And this is what it's going 
>> to be like:
>> we can't work like Mr. Climov suggested. This will split up 
>> the codebase
>> and end up in a fight whose final is better and offers the best
>> features.
>> 
>> To me, this seems like that we core-developers are dammed by 
>> Mr. Climov
>> to fix bugs and maintain the show, including answering questions of
>> newbies and taking care of the lists, while they take their time and
>> build a second version which will be theirs, just like it 
>> happened with
>> KDEStudio.
>> 
>> About KDEStudio, I'm not as pissed off as about this, because if you
>> look at the code, you see some similarities and it is clear 
>> that this is
>> another IDE but based on our effort. We on the other hand will surely
>> make use of this or that idea of KDEStudio as we're already 
>> testing the
>> dockwidget. So for the user there will be choice in one or the other
>> variant of the same code-base. But this attempt is just rediculous as
>> Mr. Climov asks KDevelop users and developers for their wishes and
>> plans. Asking me for my wishes is rediculous as I'm going to 
>> implement
>> these plans and additions with the other developers, anything else I
>> would consider to steal ideas and make a new project even 
>> stealing the
>> name.
>> 
>> 
>> And about the manageability of
>> > a branch and re-merge, it's just a matter of how much we 
>> want to do this (in
>> > fact a matter of interests). And I think that our (common) 
>> interests are to
>> > create the best IDE. In the worst case, we will have two 
>> IDE's instead of
>> > one, at the end :-).
>> I think this request already led to the worst case- you're 
>> offering this
>> as a thread : if we don't cooperate, you will go on with our codebase
>> anyway and start you own development. I don't doubt your 
>> facilities as a
>> developer nor the integrity of your corporation, but a 
>> thread like this
>> is unacceptable to me.
>> 
>> I will continue my work on THIS project, on OUR KDevelop.  I 
>> want more
>> developers to work IN our TEAM, not outside with our code on their
>> project. This is again a waste of resources and will split up users
>> again as well as developers.
>> 
>> 
>> I hope Mr. Climov has good reasons for threatening the core-team and
>> would be more clear in his way to explain his point of view and what
>> plan he exactly means. I would like to have developers help, 
>> but not in
>> an extra-team; on the other hand I can understand that he 
>> wants to have
>> his corporation work alone on a project without us. But if 
>> that is the
>> case, I please you to start from scratch by your own. Any 
>> other option
>> is not fair against our team.
>> 
>> Just my two cents.
>> I hope I didn't offend anyone too much more than necessary and
>> recommended in this case, as well as I hope that I gave some 
>> light from
>> the official side towards the users of the original KDevelop.
>> 
>> 
>> Bye,
>> 
>> Ralf
>> 



More information about the KDevelop mailing list