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

List:       kopete-devel
Subject:    [Kopete-devel] Re: Kopete does not compile
From:       Matt Rogers <matt () matt ! rogers ! name>
Date:       2003-08-29 21:19:33
[Download RAW message or body]

On Friday 29 August 2003 03:05 pm, Martijn Klingens wrote:
> On Friday 29 August 2003 21:25, Olivier Goffart wrote:
> > this time, the bug is in configure. it does not seems detect that it need
> > to compile .
>
> What does it say? Is it my configure check or something else in the generic
> kdenetwork code?
>

You configure check is broken. It doesn't return a value indicating yes or no, 
or whatever it's supposed to return. 

> Does it work if you replace admin/ in kdenetwork with KDE_3_1_BRANCH?
>
> > Martijn, don't you think we should drop kde 3.1 support?
>
> No. 3.2 is waaaaay too bleeding edge to depend upon for our users. And the
> release is still a while away. I wouldn't be surprised if we can release 
> an 0.8 before 3.2 even...
>
If 3.2 is waaaaay too bleeding edge, then why are we using the 
KConfigureDialog stuff? 

> > KDE Head will even drop qt 3.1 support on monday.
>
> True, but by maintaining an old KDE_3_1_BRANCH admin/ dir you can probably
> continue working on it.
>

We're in a main KDE module now. Maintaining compatibility with an older 
release is not required anymore, IMHO. However, we should decide if there's 
going to be a 0.8 release before we remove KDE 3.1 support. 

> > I don't have enough diskspace left on my HD to recompile it, and last
> > time i tried it, KDE was verry unstable (i compiled only kdelibs, not
> > others (just kcontrol because it's not binary compatible) )
>
> I suggest installing KDE HEAD to a separate dir and build kopete against
> that. Perhaps also kdebase. The rest can then run against the old libs
> because they are not replaced. That's what I do at home.
>
> > Anyway, after monday (which is the day of the planed features frezee) i
> > would still like to code what i planed to do in the TODO file in kopete.
> > i don't know if we should put that somewere.. i guess the "include all
> > basic features necessary for a 1.0 release" in the kde feature include
> > theses.
>
> 1. I do _NOT_ want to call the next release 1.0. No way on earth we're
> going to hit BC in time.
>

Well, how bout we try for it instead of assuming that we won't make it? I'm 
sure there's something that you know that I don't, but you don't also have to 
do it all yourself. I know of two things that need to happen to help 
establish BC, d pointers and no more new virtual functions. What else? I 
volunteer. 

> 2. Your list of TODO items is quite big and intrusive. The planned features
> list is not meant to be a 'let's add everything here so we can basically
> continue coding as if there were no feature freeze' list. Please pick only
> a couple of items and try to work on stability and bug fixing in some 6
> weeks or so instead of adding features after that.

Well, then what do you suggest? My list of TODO items it quite large as well 
and well, with the unlisted feature freeze starting Monday, I'll be using the 
"include all basic feastures necessary for a 1.0 release" as my justification 
for it.

Matt
_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]