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

List:       kopete-devel
Subject:    Re: [Kopete-devel] Re: Kopete does not compile
From:       Martijn Klingens <klingens () kde ! org>
Date:       2003-08-29 21:46:34
[Download RAW message or body]

On Friday 29 August 2003 23:19, Matt Rogers wrote:
> Your configure check is broken. It doesn't return a value indicating yes or
> no, or whatever it's supposed to return.

Do you have the relevant portion of config.log handy? That would surely help.

> > 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?

Because we're still far from a release and because providing a copy of the 
thing inside our own tree is a lot different from requiring users to upgrade 
their entire system.

> We're in a main KDE module now. Maintaining compatibility with an older
> release is not required anymore, IMHO.

What does the location of our code have to do with that? We could just as well 
host it on a private CVS server, kde-extragear or wherever we want.

What counts is our target userbase and in my opinion that userbase is far 
bigger than the KDE CVS HEAD using community and the people that immediately 
upgrade to KDE 3.2.

> However, we should decide if there's 
> going to be a 0.8 release before we remove KDE 3.1 support.

Again, the two have nothing to do with eachother. Whether there will be a 0.8 
or not has nothing to do with whether we want to drop 3.1 support.

> > 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?

Did I say we shouldn't?

> 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.

That's the theory and the easy part.

> What else? I volunteer.

_MAINTAINING_ BC after we decide to go for it. That means that much of the API 
can no longer be easily changed. For that we should take a VERY close and 
thorough look at our existing virtuals and trim some and add others. Also, we 
need a couple of months (at an absolute MINIMUM three months IMO) where we 
try to avoid doing BC changes but are still allowed to do so. This way we can 
pinpoint the locations where the API still needs improvements.

That means that BC is at least 5 months away from now and that's the most 
optimistic estimate I can make. 9 months seems more realistic.

> 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.

If you want to release another rather unstable release and rush everything in 
I'd say go for it. Personally I'd much prefer to stop adding features early, 
start stabilizing, bugfixing and do architectural improvements like preparing 
for BC, call the next release 0.8, and skip the new features for 0.9 or 1.0 
being released after KDE 3.2.
 
-- 
Martijn
_______________________________________________
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]