Weil der Plan immer noch ist, es vor 4.6.0 zu veröffentlichen. Akonadi-Kontact 4.6 zu nennen ist auch nicht wirklich praktisch, weil damit das neue Kontact nicht vor Ende Januar rauskommen kann, zusammen mit der 4.6er Plattform. Die "latest stable" von kdepim bleibt daher 4.4.x, das erspart auch etwas Arbeit weil dann ein Branch weniger zu maintainen ist, und diejenigen die 4.4 benutzen auch die letzten Bugfixes in der "latest stable" Branch mit abbekommen. Das hilft all denen, die nicht auf 4.5 upgraden, d.h. wohl den meisten Linux Benutzern.
Ich bin auch nicht gerade zufrieden, wie die Kommunikation rund um's Release Management und um den Akonadi Port von Kontact bisher gelaufen ist. Ich habe mich daher mit einigen PIM Entwicklern (u.a. Thomas McGuire, Tilll Adam, Volker Krause, Stephen Kelly) zusammengesetzt, und eine deutliche Kommunikationsstrategie ausgearbeitet. Nun ist es so, dass wir ständig dran arbeiten, dass unsere Arbeit, so komplex wie sie teilweise auch ist, den Benutzern erklärt wird, und auch wie unsere Planung aussieht. Wir sind hier in den letzten Jahren schon deutlich besser geworden -- das merkt nicht zuletzt auch ihr von Pro-Linux daran, dass wir aktiver an Announcements arbeiten, und auch Basismaterial für Artikel bereitstellen. Wann genau wir Kontakt 4.5 aus Akonadi basierend rausbringen ist halt noch nicht deutlich, es hängt vom Fortschritt bei der Stabilisierung ab. Die ist auch schon länger im Gange, nur dauert halt etwas -- niemand will einen instabilen Emailclient. Man muss hier aber auch dran denken, dass Kommunikation auch Zeit kostet. Zeit, die sicherlich gut investiert ist. Praktisch sieht's aber für mich als Entwickler auch so aus, dass ich in der Zeit in der ich einen längeren Blogeintrag schreibe, auch coden könnte. Und Coden macht halt auch Spass, und hilft Kontakt release-fertig zu machen. Catch 22.
In einem offenen Projekt wie KDE gelten die gleichen Einschränkungen denen Ihr auch unterliegt. Wenn ein "Upstream" Team keine deutliche Planung für so'ne Migration vorgibt, kann sie auch nicht deutlich kommuniziert werden, z.B. auf Events wie der FrosCon. Das ist sicherlich einer der wunden Punkte bisher bei der Migration. Das ist auch ein Grund, warum ich mir die Zeit genommen habe, die Informationen für den Blogeintrag zusammenzutragen, und es zu veröffentlichen.
Es ist daher auch hilfreich, dass ihr diesen Artikel bringt, in sofern: Danke
Weil der Plan immer noch ist, es vor 4.6.0 zu veröffentlichen. Akonadi-Kontact 4.6 zu nennen ist auch nicht wirklich praktisch, weil damit das neue Kontact nicht vor Ende Januar rauskommen kann, zusammen mit der 4.6er Plattform. Die "latest stable" von kdepim bleibt daher 4.4.x, das erspart auch etwas Arbeit weil dann ein Branch weniger zu maintainen ist, und diejenigen die 4.4 benutzen auch die letzten Bugfixes in der "latest stable" Branch mit abbekommen. Das hilft all denen, die nicht auf 4.5 upgraden, d.h. wohl den meisten Linux Benutzern.
Ich bin auch nicht gerade zufrieden, wie die Kommunikation rund um's Release Management und um den Akonadi Port von Kontact bisher gelaufen ist. Ich habe mich daher mit einigen PIM Entwicklern (u.a. Thomas McGuire, Tilll Adam, Volker Krause, Stephen Kelly) zusammengesetzt, und eine deutliche Kommunikationsstrategie ausgearbeitet. Nun ist es so, dass wir ständig dran arbeiten, dass unsere Arbeit, so komplex wie sie teilweise auch ist, den Benutzern erklärt wird, und auch wie unsere Planung aussieht. Wir sind hier in den letzten Jahren schon deutlich besser geworden -- das merkt nicht zuletzt auch ihr von Pro-Linux daran, dass wir aktiver an Announcements arbeiten, und auch Basismaterial für Artikel bereitstellen. Wann genau wir Kontakt 4.5 aus Akonadi basierend rausbringen ist halt noch nicht deutlich, es hängt vom Fortschritt bei der Stabilisierung ab. Die ist auch schon länger im Gange, nur dauert halt etwas -- niemand will einen instabilen Emailclient.
Man muss hier aber auch dran denken, dass Kommunikation auch Zeit kostet. Zeit, die sicherlich gut investiert ist. Praktisch sieht's aber für mich als Entwickler auch so aus, dass ich in der Zeit in der ich einen längeren Blogeintrag schreibe, auch coden könnte. Und Coden macht halt auch Spass, und hilft Kontakt release-fertig zu machen. Catch 22.
In einem offenen Projekt wie KDE gelten die gleichen Einschränkungen denen Ihr auch unterliegt. Wenn ein "Upstream" Team keine deutliche Planung für so'ne Migration vorgibt, kann sie auch nicht deutlich kommuniziert werden, z.B. auf Events wie der FrosCon. Das ist sicherlich einer der wunden Punkte bisher bei der Migration. Das ist auch ein Grund, warum ich mir die Zeit genommen habe, die Informationen für den Blogeintrag zusammenzutragen, und es zu veröffentlichen.
Es ist daher auch hilfreich, dass ihr diesen Artikel bringt, in sofern: Danke