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

List:       kde-pim
Subject:    [Kde-pim] Re: Do we need a Beta3?
From:       Till Adam <adam () kde ! org>
Date:       2010-12-12 13:41:30
Message-ID: 20101212134247.E63CC46B6018 () mail ! kdab ! com
[Download RAW message or body]

Will, folks,

On Friday 10 December 2010 16:44:40 Will Stephenson wrote:
> On 10/12/10 16:15, Thomas McGuire wrote:

> > On Friday 10 December 2010 11:54:45 Will Stephenson wrote:
> >> On 10/12/10 11:27, Andras Mantia wrote:
> >>> Having an extension for the beta time by itself will not help. If
> >>> nobody fixes bugs, they won't go away. If developers cannot find
> >>> time to work on kdepim, that's fine, but in this case we should
> >>> consider of not releasing kdepim together with 4.6.0. I wish we
> >>> could, but releasing in its current state will do more harm than
> >>> good, as there are obvious shortcomings both in migration (very
> >>> important!) and daily usage.
> > 
> > I agree with Andras here as well, having another beta won't gain us
> > much.
> > I'll stay out of the discussion whether or not to release KDEPIM with
> > KDE 4.6 or not, as I don't know the current state well enough for that.
> > KDEPIM definitely would benefit from more developers, as otherwise bugs
> > indeed won't get fixed. Thankfully, there are some developers like
> > Tobias, Laurent and Andras actually using KMail2 and therefore
> > contributing some bugfixes, which is great. However, IMHO there needs
> > to be a bigger developer base for having a healthy project.
> > 
> >> Agreed. And I don't know how it will improve because there is no
> >> communication from whoever is managing the kmail2 work in KDE PIM or
> >> at
> >> KDAB.
> > 
> > There is no communication because nobody really is managing the work.
> > The
> > developers doing KMail2 bugfixes right now do it to fix their own
> > problems, there is no "managing" involved. And KDAB is working on the
> > mobile version, so don't expect any desktop work coming from there. Of
> > course, the shared bits like Akonadi benefit from the mobile work a
> > lot.
> > So since there the work on the desktop version is not much, there is
> > also not much communication.
> 
> That's very unfortunate.  I believed that when you stood down as KMail
> maintainer, it (and the other major parts of Kontact) would continue to
> be maintained by KDAB as the core of the Kolab client, and since KDAB
> hired the entire set of available kde-pim developers.   What happened to
> that work?  And why hasn't anyone raised a red flag that KMail
> development is basically rolling along without a driver so the rest of
> the KDE project knows about it and can try to help?

Let me describe what's currently going on at KDAB, in this space, maybe that 
helps clarify things a bit. The Kolab client team is presently very busy 
finishing the Windows CE mobile version of Kontact, which we were contracted to 
build. This work has yielded the Maemo and MeeGo versions, as side effects, and 
already benefitted the desktop versions immensely, since we had to do a lot of 
stabilization and performance work that applies across the platforms. The IMAP 
sync is orders of magnitudes faster, kmail as a whole is much smaller and 
faster, etc. Right now, we are in bugfixing phase, which means several people 
are working full time to iron out the last remaining issues in the mobile 
versions. A lot of these issues are also relevant for the desktop versions, as 
you can quite easily tell if you read the hundreds of commits going in per 
week from us.

Once the currently ongoing mobile work  concludes (end of Januar, it looks 
like) we are hopeful to secure more funding that will be focused on the 
desktop again, bringing those platforms to full product maturity as soon as we 
can. Note that the target quality there will be well beyond what I would 
consider ok to release as part of KDE 4.6. Others might differ.

Right now, nearly all of what we do is useful and beneficial for the desktop 
Kontact, since we are focusing on performance, stability and robustness and 
bugfixing. There are a few areas that are out of scope of the project and we 
can thus only care for as time and resources permit. These are:

- migration, which is not relevant on the mobile platforms, no previous data 
there
- POP3, as it is not relevant for the enterprise use cases we are paid to care 
for
- performance problems that are specific to the desktop version, such as in 
some headers list themes
- problems steming from the use of nepomuk, which is not available on mobile 
and has been replaced with a pure strigi based full text search
- problems that appear as a result of distro packaging, such as AppArmor and 
other MySQL setup issues

Many of us have worked on all of these in our spare time, with already quite 
nice results, but those areas still need the most work. This, I think, is also 
apparent from the beta feedback.

So KDAB hasn't abandoned Kontact by any means, we continue to contribute 
heavily to it and of course we also, as a group, along with those not paid to 
work on Kontact in the kdepim community, have an idea of where we want it to 
go. We try to align the project work with the KDE releases as much as we can 
and make sure our work has maximum benefit for KDEPIM. But there are things we 
simply can't fully take responsibility for, at least no all the time and all 
of Kontact, so any and all contribution from others is more than welcome. We 
would prefer non-paid maintainers for the applications, if possible, since we 
believe a strong counter weight for our business interests would benefit 
everyone, but in the absence of that, we are doing what we can to move things 
along. 

As to the question whether we need another beta, I think that more feedback 
and time to work on incorporating that would be helpful, but by itself it 
won't solve the underlying problem that everyone seems to think that the Kolab 
guys will just magically fix everything if we just keep pushing the release 
back long enough. I do think that Kontact as it is in trunk right now, and 
particularly KMail are quite ok and usable, at least if one is on the well 
tested and debugged path of IMAP + local folders and doesn't run into 
migration or nepomuk issues. There are/were a few annoying things like the 
imap resource getting stuck or the unread counts going out of sync, but we 
believe those to be fixed (as part of our project work, btw).

In short: we do need help in kdepim (we've been saying so for years), there's 
a lot of KDAB work going on to help out, I personally think releasing kdepim 
with 4.6 is the right thing to do, we should try to get as much high quality 
feedback as we can, in particular for migration, and we should try to get some 
more KDE hackers from the wider ecosystem to help out, like Thiago, David and 
others have started doing after beta 1, with great results.

Cheers,

Till



_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic