Re: [Kde-pim] KDEPIM Needs More TIme
On Friday 14 May 2010, Allen Winter wrote: Howdy All, I regret to inform everyone that kdepim will not be ready for a 4.5 Beta1 that is scheduled to happen in a few days. We estimate an extra month will be needed. Unfortunately, the massive porting effort to Akonadi (an even bigger job than the Qt3/KDE3 - Qt4/KDE4 port) is taking longer than we anticipated. So, we have a couple of choices: 1) insert a 1 month long alpha [1], thereby delaying 4.5.0 by 1 month 2) keep kdepim out of 4.5.0 and release it separately 1 month later 3) keep kdepim out of 4.5.0 and release it again for 4.6.0 Of course, I'd opt for choice 1. But there is simply no way we can put kdepim out there even in a beta at this time. My suggestion (as an outsider) is to opt for choice 3 or, more precisely, to opt for the following variant of 3: - Take the time until 4.6.0 to make the Akonadi port of kdepim rock. - Move current trunk/KDE/kdepim to a branch. - Copy current branches/KDE/4.4/kdepim to trunk, i.e. revive kdepim 4.4 for KDE SC 4.5. - Probably keep kaddressbook trunk. - Optionally, spend the time until 4.5.0 to fix the most annoying shortcomings in kdepim 4.4. IMHO it does not make any sense to rush the completion of the Akonadi port of kdepim. We got enough beating (e.g. on kdepim-users) for releasing the incomplete rewrite of KAddressBook with all of its migration problems with 4.4. To prevent a similar experience with the Akonadi ports of KMail, KOrganizer, etc., we need an extended alpha and beta phase, not shortened ones. If the Akonadi port of kdepim is ready for alpha or beta testing in a couple of months then we can (and should) make an alpha/beta release of kdepim (based on KDE SC 4.5) for those who are willing to play guinea pig. Just my 2 cent as former maintainer of KMail and as support engineer for problems with kdepim 4.4 (mostly KAddressBook), Akonadi and Nepomuk on kdepim-users. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM Needs More TIme
On Thursday 20 May 2010 11:36:15 Dirk Mueller wrote: On Monday 17 May 2010, Sebastian Kügler wrote: If that's not achievable in the 4.5 timeframe, maybe we should start thinking about 4.6 instead? so kdepim should be excluded from 4.5 tagging. what about kdepimlibs? will kdepimlibs 4.5 work with kdepim 4.4? Anecdotally, yes. has this been tested? Raymond has been providing a packaged build of pim 4.4 on pimlibs 4.5 + the rest of trunk for a while now here: https://build.opensuse.org/project/packages?project=home:rwooninck:kdepim45:kdepim44 Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM Needs More TIme
On Monday 17 May 2010, Sebastian Kügler wrote: If that's not achievable in the 4.5 timeframe, maybe we should start thinking about 4.6 instead? so kdepim should be excluded from 4.5 tagging. what about kdepimlibs? will kdepimlibs 4.5 work with kdepim 4.4? has this been tested? Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM Needs More TIme
On 05/20/2010 11:36 AM, Dirk Mueller wrote: so kdepim should be excluded from 4.5 tagging. what about kdepimlibs? will kdepimlibs 4.5 work with kdepim 4.4? has this been tested? There was a discussion about this in #kde-devel yesterday where tmcguire reaffirmed that this was the intended com- bination and said they had people running it as well. Greetings, Dirk -- Best regards, Eike Hein ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM Needs More TIme
On Monday 17 May 2010 18:55:02 Anne Wilson wrote: On Monday 17 May 2010 16:05:17 Cornelius Schumacher wrote: On Monday 17 May 2010 Sebastian Kügler wrote: What is so hard about migrating config data? At least the account setup doesn't look too complicated to the naive me. Migrating config data is very hard. You have to deal with an awful lot of details, weird setups, configs which were migrated over many years again and again, and you have to get it 100% right, otherwise users will be annoyed. It's also tremendously hard to test as you usually don't have access to a wide variety of test configs, and developers don't notice issues, as they do the migration of their own data only once. So this needs a lot of hardening, and a lot of attention to details. We should really take the time to do it properly. Any problems with that will badly reflect on Akonadi, which we really have to avoid. The current opinion of Akonadi is already bad enough. Users can live with the details of setup - minor things like layouts, for instance - but account details - the ability to send and receive mail based on the account settings already present - would be important to them. We can prepare users for the need to reconfigure the lesser things, but if account details are lost I predict that all hell with let loose. That's what I was thinking of. I guess most users can live if not /all/ options are taken over by the new version. It would be really nice though, if the harder to set up things like Identities, Signatures and Accounts and Filters could be retained -- those usually take a lot of time to set up which would influences the user's happiness when the new KMail first starts. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM Needs More TIme
On Monday 17 May 2010 Sebastian Kügler wrote: What is so hard about migrating config data? At least the account setup doesn't look too complicated to the naive me. Migrating config data is very hard. You have to deal with an awful lot of details, weird setups, configs which were migrated over many years again and again, and you have to get it 100% right, otherwise users will be annoyed. It's also tremendously hard to test as you usually don't have access to a wide variety of test configs, and developers don't notice issues, as they do the migration of their own data only once. So this needs a lot of hardening, and a lot of attention to details. We should really take the time to do it properly. Any problems with that will badly reflect on Akonadi, which we really have to avoid. The current opinion of Akonadi is already bad enough. -- Cornelius Schumacher schumac...@kde.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM Needs More TIme
On Monday, May 17, 2010 11:05:17 Cornelius Schumacher wrote: On Monday 17 May 2010 Sebastian Kügler wrote: What is so hard about migrating config data? At least the account setup doesn't look too complicated to the naive me. Migrating config data is very hard. You have to deal with an awful lot of details, weird setups, configs which were migrated over many years again and again, and you have to get it 100% right, otherwise users will be annoyed. I completely agree, but is there some standard-ish layout that most users have? It may make sense to support migrating a very commonly used configuration, or group of options, if it's not too difficult, while letting users know that it can't be supported for other configurations. e.g. it's probably better to be able to migrate at the very least accounts and passwords instead of the font for every possible widget view KMail has. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM Needs More TIme
On Saturday 15 May 2010 7:26:00 am Will Stephenson wrote: On Friday 14 May 2010 14:49:34 Allen Winter wrote: On Friday 14 May 2010 8:42:21 am Allen Winter wrote: Howdy All, I regret to inform everyone that kdepim will not be ready for a 4.5 Beta1 that is scheduled to happen in a few days. We estimate an extra month will be needed. Unfortunately, the massive porting effort to Akonadi (an even bigger job than the Qt3/KDE3 - Qt4/KDE4 port) is taking longer than we anticipated. Forgot to mention that Thomas' blog has a lot more details. http://thomasmcguire.wordpress.com/2010/05/14/akonadi-meeting-and-the-kde-s c-4-5-release I recommend releasing 4.5 without kdepim as was done with 4.0 and doing an interim kdepim release cycle (call it akonadi tech preview) before 4.6. This gives us a way to soft-launch the major Akonadi ports without the full expectations coupled to being in the SC, and gives us some nice things to talk about between 4.5 and 4.6. I'm ok with that. But who will do the work of making the ATP release? Someone from the kdepim team will need to make the ATP -- volunteers? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
