Dropping QT from libkolab would be a complete rewrite of it, and also mean we no longer use any KDE libraries.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed Search
Apr 27 2015
Apr 27 2015
Apr 24 2015
Apr 24 2015
mollekopf renamed T59: Port libkolab away from KDateTime from Port away from KDateTime to Port libkolab away from KDateTime.
mollekopf renamed T58: Port libkolab away from KSystemTimeZone from Port away from KSystemTimeZone to Port libkolab away from KSystemTimeZone.
Apr 21 2015
Apr 21 2015
Apr 20 2015
Apr 20 2015
And to add to the fun a windows build would of course be awesome to keep that side building.
Apr 18 2015
Apr 18 2015
Apr 17 2015
Apr 17 2015
Apr 14 2015
Apr 14 2015
mollekopf committed rKB4983e40734ae: catch exception here too (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKBdca90933c944: Fix race on static map. (authored by David Faure <faure@kde.org>).
mollekopf committed rKB7e583d140d04: Catch more exception. I hope that it will fix all crash about it (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKBb52729b29368: Catch exception here too (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKB7ac167023011: Fix indent contact group (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKBe355b88ea312: Add more unittest for contact group (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKB18ffc5d87a73: Add missing mimetypes (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKBbd7b75f67d06: Add more contact group unittest (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKB3cfe88c62ebc: XapianDB: We only need the headers for malloc_trim (authored by Vishesh Handa <me@vhanda.in>).
mollekopf committed rKBa7e4cf9c3e86: Remove duplicate code (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKB0c4035fc9466: Start calendar indexer (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKB3e20aa719d56: Index birthday need by kontact plugins birthday (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKBd443799db7c2: Improve calendar support (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKB485145a9b099: Continue to implement calendarindexer (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKB810addf1ccd3: Add KABC::ContactGroup::mimeType() (authored by Montel Laurent <montel@kde.org>).
mollekopf committed rKB315832905d15: Calendar event needs to be indexed too. Start to implement it (authored by Montel Laurent <montel@kde.org>).
mollekopf added a reverting change for rKB763538dcf6da: Akonadi Agent: Introduce a scheduler: rKB47c53c1cadef: Revert "Akonadi Agent: Introduce a scheduler".
mollekopf added a comment to T2: How would you like to work with KDE PIM Source Code Management Repositories?.
In T2#148, @vanmeeuwen wrote:In T2#145, @mollekopf wrote:At least for the moment I'd like to avoid cloning (which seems to imply that we have a read-only mirror of the relevant repository). We currently rely on our own copy for development branches, although we may be able to move that upstream if the branching policies are adjusted upstream.
To me the separate repositories don't complicate work, so that works well enough for me.We should consider work against a third-party upstream goes to if not through that third-party upstream, and attempt to figure out upstream how we can collaborate with them, rather than maintain a fork of a git repository (w/ or w/o special branches of our own).
After all, upstream should have a level of interest in our participation -- however low, and we should have a level of interest in providing our work upstream -- however biased wrt. priorities.
Noted this is the ideal scenario, and we'll likely end up with a less than ideal scenario in real life, we are establishing an exceptional situation hopefully for the time being.
However, our work downstream is structured with Scrum Sprints, and it is in that light we need to view how this work downstream aligns with work happening upstream (largely uncontrolled).
I would favor a scenario in which the KDE PIM upstream repositories are mirrored completely, and the branches we push to have a canonical naming convention -- we would block pushes to branches with names not approved prior to the fact (using Herald).
mollekopf added a comment to T2: How would you like to work with KDE PIM Source Code Management Repositories?.
At least for the moment I'd like to avoid cloning (which seems to imply that we have a read-only mirror of the relevant repository). We currently rely on our own copy for development branches, although we may be able to move that upstream if the branching policies are adjusted upstream.
To me the separate repositories don't complicate work, so that works well enough for me.