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

List:       kde-devel
Subject:    Re: mico 2.2.6
From:       David Faure <faure () alpha ! tat ! physik ! uni-tuebingen ! de>
Date:       1999-05-20 20:55:16
[Download RAW message or body]

On Thu, May 20, 1999 at 10:49:41PM +0200, Simon Hausmann wrote:
> On Thu, 20 May 1999, David Faure wrote:
> 
> > On Thu, May 20, 1999 at 07:29:33PM +0200, Harri Porten wrote:
> > > Hi !
> > > 
> > > Simon Hausmann wrote:
> > > > 
> > > > On Wed, 19 May 1999, Cristian Tibirna wrote:
> > > > 
> > > > > I have mico-2.2.6 for 5 weeks already. How can I help (what pieces of code
> > > > > will need fixes and will not get people work on it)?
> > > > 
> > > > Thanks for your offer :)
> > > > 
> > > > One thing comes to my mind:
> > > > 
> > > > Help us finishing kded :)
> > > > 
> > > > Most stuff is working fine already, but I think it needs some
> > > > polishing and testing.
> > > 
> > > I wanted to mention that I just started to "try to understand" the KOM,
> > > OpenParts etc. stuff as well. Since kded is certainly not the easiest
> > > part to begin with I'll concentrate on easier tasks first.
> > > 
> > > I switched to mico-2.2.6 yesterday. Are the compile errors in
> > > kdelibs/corba the problems you were talking about ?
> > 
> > Those problems are 'simple' porting stuff, which Steffen and Simon have
> > already done on their hdd. When they say "we all switch", I suppose
> > they will also commit the necessary changes.
> 
> No problem, I'm ready to commit _ALL_ necessary changes.
> 
> > The problem is not that, but kded still not working well, so object
> > trading would be broken. Perhaps we should apply those changes in a branch
> > (like MICO_2_2_6) so that more people can test it with 2.2.6 ?
> > Or this is stupid and let's simply switch and temporary lose embedding...
> > Don't know.
> 
> Wellwell, *I* don't really care and know ;-)
> 
> *If* everyone agrees I can commit all stuff.
> 
> But in somehow I don't like the extra-branch idea very much. Just my
> personal taste :) , I think it's a little bit confusing.
> 
> So IMO: _WHEN_ switching, then let's switch really, withouth an extra tag.
> 
> And: Switching now makes integrating kded easier IMO, since it wouldn't
> require an all-in-one-really-huge commit, which would then include, beside
> the mico porting stuff for kdelibs/konqy/koffice, also _all_ (upcoming)
> changes with some .desktop files for the services, so that the trader is
> able to find some koffice plugins and stuff _and_ the changes in
> libkofficecore to call the trader+activator in kded.
> 
> It's not my decision :) . I can commit all stuff *now* (tonight) _or_ at
> the end of the next week (because I'll have no net-access the next
> week ).

ok, ok ..

I would say "let's switch", but be prepared for tons of bug reports on koffice@ :))

How long do you think before kded is ready (in the sense that it can replace
koffice's trader ?)

I don't think we all need to say "yes" to the switch. Let's simply say that if nobody
objects (and it doesn't seem that anybody objects) then we'll switch asap.

/me is glad that he didn't use embedded stuff in his kpresenter demo,
ready for the French Linux Expo :)

So : just announce the switch, commit the changes, and update the minimum mico version
required in the configure.in[.in] scripts.

-- 
David FAURE
david.faure@insa-lyon.fr, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today

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