Konqueror questions.
Till Adam
till at kdab.net
Mon Oct 1 19:16:35 CEST 2007
On Monday 01 October 2007 17:52:05 Allen Winter wrote:
> On Monday 01 October 2007 1:06:38 am Dirk Mueller wrote:
> > On Tuesday, 25. September 2007, Albert Astals Cid wrote:
> > > And if that's still not clear, that can well be because doing complex
> > > sentences in english is not my strong point, i'll rephrase it.
> > >
> > > I have "hope" we can have them "working" for KDE 4.0
> >
> > I still don't get it. KDEPim 4. was not declared a show stopper for 4.0
> > before. I agree that bugs in the libraries that are possibly exposed by
> > kmail, but maybe also by other applications have to be fixed. but that is
> > not the same level as saying "kmail is a ship stopper".
> >
> > There is nobody working on KDE Pim for 4.0, and with nobody working on
> > it, the amount of time needed for getting it ready is definitely
> > unpredictable.
> >
> > BTW: last time I tried to use kmail from KDE 4.0, it deleted all my
> > folders. I was not too happy about that. (but I've learned meanwhile that
> > for kmail, its always good to have backups).
>
> Yes, we may have to remove KMail as a 4.0 showstopper.
> We may have to remove kdepim entirely from the 4.0 release.
>
> I don't know yet.
>
> I was told several months ago that kdepim was going to receive
> a large increase in manpower by now... not sure what happened.
I guess you are refering to the KDAB/Kolab Konsortium team here, so let me try
to give you a bit of background on this. There is in fact a sizeable team at
KDAB working on kdepim, atm, has been, for months, but currently not (yet)
focused on stabilizing trunk overall. Namely Marc, Frank, Laurent, Volker,
Andreas, Thomas, Pradeepto and myself, with help from David. We're working in
several areas, atm:
1) Maintaining the ultra stable proko2 branch, the Kolab client still used by
many Kolab users.
2) Implementing contracted features and bugfixes on top of the 3.5 code base,
namely the enterprise branch, those were forward ported to trunk, until that
froze, and are now forward ported into a temporary work branch of trunk, to
be merged when trunk unfreezes. Bugfixes also go into 3.5 as applicable. The
reason for the branch is the feature and docs freeze on 3.5, of course.
3) Fixing and extending the crypto infrastructure in trunk and making it work
on all of KDE's target platforms, specifically Windows. This also happens in
a branch, atm, and will of course also be merged into trunk at the earliest
opportunity. This includes a merge of kpgp and kleopatra, among other things.
4) Based on trunk and the work from 2) and 3), building the next generation
Kolab client.
The timelines for these activities are:
1) is to go on for as long as we have customer interest in it.
2) will continue until the end of November, at which point all contracted
bugfixes and features will be done. This then goes into maintainance mode.
3) will be done by the middle of November.
4) is ongoing, albeit overshadowed by the others, and will pick up steam once
2) and 3) are complete.
This means that we will start focusing on kdepim trunk in general towards the
end of November and keep at it until we have a stable Kolab client (Kontact,
in other words) based on KDE4.
That said, we will try to free up some time to help get KMail usable in trunk
in time for 4.0, but overall we are driven by customer schedules and
priorities more than KDE schedules, I'm afraid, at least in our paid time.
Many of us also spend spare time on KDE, in various areas, but of course that
time is not subject to KDAB scheduling.
Hope that clarifies things a bit,
Till
--
Till Adam -- till at kdab.net, adam at kde.org
KDAB, Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20071001/3defc55a/attachment.pgp
More information about the release-team
mailing list