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

List:       kopete-devel
Subject:    Re: [kopete-devel] Kopete Development Status
From:       Matt Rogers <mattr () kde ! org>
Date:       2005-11-16 13:27:30
Message-ID: 200511160727.30731.mattr () kde ! org
[Download RAW message or body]

On Wednesday 16 November 2005 04:21, Olivier Goffart wrote:> Le Mercredi 16 Novembre \
2005 06:26, Matt Rogers a écrit  :> > Hi,> >> > This message is to give everybody an \
overview of what's going on in> > Kopete development land ATM. If people find these \
useful, I can post them> > on a schedule.> >> > Kopete 0.11> > ===============> > \
[...]> >> >> > Kopete 0.12> > ===============> > Any sort of heavy development that \
you want to be targeted for a KDE 3.x> > release should be happening here.> > \
Highlights from this branch:> >   - merge from KDE 3.5 branch on 11/15/05> >   - \
XHTML+CSS instead of XSLT in the chatwindow, protocol improvements,> > and bugfixes \
are the focus of this release> >   - no firm release date set. There will be a \
release from this branch.> > It is somewhat dependant on how fast people move to KDE \
4 after KDE 3.5> > is released and how long the XHTML+CSS feature takes.>> Will there \
be a time of frezee ?> Yes, there will be a freeze. I can't say when because there's \
no firm release date yet. I'm waiting to see how things evolve with the XHTML+CSS \
stuff first before thinking of release schedules and freezes and things like that.
> > Kopete 1.0 (trunk, KDE4, version number is tentative)> > ===============> > Merge \
> > from dev-0.12 happened on 11/15.> > Some of the current tasks available to be \
> > worked on are:> >  - Porting protocols and plugins to Qt4 using the qt3support \
> > library to> > make it compile> >  - getting rid of qt 3 support in ported code> > \
> > - adding unit tests for current classes where possible and refactoring> > other \
> > classes to make them more testable.>> I don't think we should make _all_ protocol \
> > and plugin compile, it's too> hard to make change in libkopete if we have to care \
> > about each plugins. We> should target few plugins in the first time.  For now, i \
> > only use testbed.>
We need to make it all compile, or start removing less used or less important \
plugins. Or perhaps we do like what kdelibs does and create a snapshot branch to port \
plugins/protocols against and maintain a specific porting guide and better api docs, \
etc.
> > I'd like to know WHO is going to work on kopete and on what branch.> Personally, \
> > i'd like to work on trunk, to refactor libkopete.  But i don't> want to do it \
> > alone.> It would be nice if poeple could reply this mail to see who will work> \
> > where.
It would be even better if we had another thread for this. :)-- \
Matt_______________________________________________kopete-devel mailing \
listkopete-devel@kde.orghttps://mail.kde.org/mailman/listinfo/kopete-devel


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