---------- Forwarded Message ----------
Subject: [Kde-pim] KDEPIM 4.5 releases Date: Wed 7 July 2010, 1:32:29 am From: Thomas McGuire mcguire@kde.org To: kde-pim@kde.org
Hi,
we had a KDEPIM BoF at Akademy today, the meeting notes can be found at http://community.kde.org/KDE_PIM/Meetings/Akademy-2010.
Basically the state of KMail 2 is not something that can be called "beta", too many problems with it, mainly with migration and filtering, but also some other blocking issues.
So the plan we discussed basically is: - The tarball that was created recently and named "beta1" is nowhere near beta1 quality. It is already packaged though, so we can't withdraw it, we only can communicate it correctly to manage expectations - We release a beta version of KDEPIM from the 4.5 branch each time a minor release of KDE SC 4.5.x is done. This means next beta gets released with KDE SC 4.5.0, the one after that with KDE SC 4.5.1 and so on. We release the final version of KDEPIM from the 4.5 branch once we deem it is in a releasable state, at the very least with KDE SC 4.6.0. - The bugfixing work will take place in the 4.5 branch, not trunk. More on that in a separate email. - Trunk is open for all commits again, including new strings and features. People should work on the 4.5 branch as their main branch though, and only commit to trunk in exceptions. Use 4.5 as the main branch to make KDEPIM ready for the release! Exceptions to that being, for example: - Feature merges from e35, e4 and komo - Patches that introduce new features from non-core developers - etc - The Komo branch, where the development for the mobile PIM applications was done, will be merged this or next week to trunk, and then removed. - kdepim and kdepimlibs will depend on kdelibs 4.5.x, _not_ kdelibs trunk. That means no new API from kdelibs trunk may be used. As an exception, the macro KDE_IS_VERSION can be used to conditionally compile in stuff that depends on kdelibs trunk. The RTL patch from Ebrahim comes to my mind here. Note that for now we still depend on kdelibs 4.4, please wait for an announcement from Volker that we can actually depend on kdelibs 4.5. Should happen soon.
Please correct me if I missed anything or if something is not correct. Also, please add any additions if you have.
Regards, Thomas
-----------------------------------------
Ryan Rix wrote:
- We release a beta version of KDEPIM from the 4.5 branch each time a
minor release of KDE SC 4.5.x is done. This means next beta gets released with KDE SC 4.5.0, the one after that with KDE SC 4.5.1 and so on. We release the final version of KDEPIM from the 4.5 branch once we deem it is in a releasable state, at the very least with KDE SC 4.6.0.
Ugh, looks like this thing will be in unstable for a looooong time (and may end up having to get Epoch-bumped out of Rawhide as we did for KOffice twice and K3b once :-( ).
Kevin Kofler
On Wed, 7 Jul 2010, Kevin Kofler wrote:
Ryan Rix wrote:
- We release a beta version of KDEPIM from the 4.5 branch each time a
minor release of KDE SC 4.5.x is done. This means next beta gets released with KDE SC 4.5.0, the one after that with KDE SC 4.5.1 and so on. We release the final version of KDEPIM from the 4.5 branch once we deem it is in a releasable state, at the very least with KDE SC 4.6.0.
Ugh, looks like this thing will be in unstable for a looooong time (and may end up having to get Epoch-bumped out of Rawhide as we did for KOffice twice and K3b once :-( ).
Given these new developments, I've untagged this from rawhide, and removed the builds from kde-unstable for now... pending further discussion and planning.
-- Rex
Rex Dieter wrote:
Given these new developments, I've untagged this from rawhide, and removed the builds from kde-unstable for now... pending further discussion and planning.
I guess I jumped the gun. I stumbled upon it this morning and installed it.
Migration went smoothly (no glitches with kwallet, emails or mail providers). Ok, there was one minor problem: I had to change the ownership of kmail2rc from root:root to me:me to make the file read/writeable.
I can receive/read emails and everything appears to work (fonts are smaller than they were previously). I haven't tried sending an email yet, admittedly. Otherwise, it doesn't really appear any different, except that now the mail transports are in akonadi.
Rex Dieter wrote:
Given these new developments, I've untagged this from rawhide, and removed the builds from kde-unstable for now... pending further discussion and planning.
I guess this is material for the next meeting.
Doing something like for KOffice, where we optimistically put stuff into Rawhide and kde-unstable, then Epoch-bumped late in the Fedora release schedule when it didn't make it, but put the stuff into kde-unstable for the pending release at that point, might be doable. On the other hand, it's a recipe for inflating Epoch, unless we're ready to ship whatever is there when F14 releases, stable or not. kdepim already has Epoch 6, kdepim-runtime doesn't have an Epoch yet.
Shipping whatever's there when F14 releases (i.e. shipping it in F14 even if it hasn't made it out of beta by then, just not pushing it as an update to existing releases at least until it gets stable, if ever) is what I'd personally argue for, but I might not have many "friends" defending this, and I realize it can be a disaster, remember how I wanted to ship F8 with KDE 3.94.0? ;-) That "beta" version turned out to be mostly unusable junk.
Kevin Kofler
On Wednesday 07 July 2010 02:30:29 Rex Dieter wrote:
Given these new developments, I've untagged this from rawhide, and removed the builds from kde-unstable for now... pending further discussion and planning.
I hope, you're shipping KAddressbook 4.5 with F14. It was already migrated to Akonadi with SC 4.4, but the 4.4 release has a few regressions, like missing multiple "Instant Messaging" address fields.
Markus
Why does it seem that KDE PIM in general was given a much lower priority in the the move to KDE 4, as opposed to things like KWin, and Plasma?
Arthur Pemberton wrote:
Why does it seem that KDE PIM in general was given a much lower priority in the the move to KDE 4, as opposed to things like KWin, and Plasma?
Because it was? ;-)
Akonadi was supposed to be one of the "pillars of KDE 4" right from the start (i.e. 4.0). But while most other components of KDE 4 released ports to the new technology with 4.0 even when it was far from ready, leading to the most buggy KDE ever, kdepim, after missing 4.0 entirely due to the apps not being ported in time because everyone was waiting for Akonadi, decided to complete the ports for 4.1 as straight ports of the KDE 3 versions, with very few changes.
Even application-level changes such as new MVC-based list views for KMail were postponed away from 4.1 and came only in later 4.x releases. On one hand, this allowed making kdepim 4.1 a very stable release and pretty much a drop-in replacement for 3.5, but on the other hand, this meant Akonadi was still stuck in the future and with no obvious place and time to introduce it.
The kdepim team then tried again and again to gradually phase in Akonadi: in 4.2 and 4.3, each time they were trying to tell us "Akonadi is now a core part of KDE, make sure you make it work by default", but each time it turned out to be optional and not used by much if anything. (Well, KPilot started using it soon, but if you don't own a Palm, you don't care about that at all.) Then, in 4.4, we finally got 1 (ONE!) of the core kdepim apps using Akonadi, namely KAddressBook, but none of the other Akonadi ports were ready in time.
Enter 4.5. By now, the rest of KDE is entering or has already entered a phase of stability, with the rate of change slowing down and the maturity and reliability going up; kdepim, on the other hand, still has the big transition they were supposed to provide with 4.0 pending, so the kdepim team decided to finally bite the bullet with 4.5 (after they missed the merge window for 4.4). So they merged the Akonadi branch of all of kdepim into the trunk wholesale soon after 4.4 branched, when it was clearly not releasable yet, hoping to complete the work on the trunk. What happened as a result is that the trunk, and now the 4.5 branch as well, ended up in an unstable state and will now not be releasable as a stable release with KDE 4.5.0, and since this all happened in the trunk, not a development branch, there was no good plan B. (The only thing they could have done is overwriting the stuff with the 4.4 branch, throwing out all the 4.5 development entirely.)
The way I, as an observer, see the problem is twofold: the changes are way too ambitious, and they're being implemented too slowly. The amount of planned changes does not fit the rate of development at all. Thus, we end up with something that's 6 releases, i.e. 3 years, late compared to the already heavily delayed KDE 4.0, and with a destabilizing major change being shoehorned into a KDE where the global trend has already been stabilization for a while.
I personally think Akonadi should have been postponed to a possible KDE 5 or scrapped entirely, but I also see the limitations of the "change as little as possible" approach: Kompare was ported that way (by me), so it suffered very few regressions, but it also still has most of the same bugs the KDE 3 version had, almost no new features and it's still using *3support legacy crap (which is now finally being ported away from, but those changes also caused 2 regressions which are now fixed and maybe more which we're yet to discover, and there's still *3support usage left). On the other hand, some of the rewritten stuff everyone including me has been complaining about is now working really well and has surpassed the KDE 3 version (whereas other stuff still leaves much to be desired, rewriting requires a lot of effort to get right).
Disclaimer: This is how I recall the history. I am not a kdepim developer, and one or the other detail might be inaccurate. Please take all the above with a grain of salt.
Another disclaimer: In the above, "KDE" refers to the software compilation released by the KDE project. Feel free to call it "KDE SC" or whatever new thing the KDE project's marketing people think of next. ;-) Any complaints about naming will be IGNORED.
Kevin Kofler
On Wednesday, July 07, 2010 06:10:57 am Kevin Kofler wrote:
Another disclaimer: In the above, "KDE" refers to the software compilation released by the KDE project. Feel free to call it "KDE SC" or whatever new thing the KDE project's marketing people think of next. ;-) Any complaints about naming will be IGNORED.
Yes, you can call it KDE SC but only internally and as we don't have anything like internal/external space (we are not MS/Apple/Whatever), please use name upstream wants you to use. KDE SC was miscommunication and never intended to be used at all (but it wasn't clear in the time).
R.
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org