Backporting Nepomuk changes

[Vishesh Handa]

Hello Release Team

I'm a Nepomuk developer. I'm requesting permission to backport a large
number commits in kde-runtime.

I created a branch called 'nepomuk/mergerRefactoring', that optimized and
fixed certain bugs in the ResourceMerger. The ResourceMerger is used when
large amounts of data are pushed in Nepomuk, eg - Strigi indexing. The
branch refactors the code and remove a TransactionModel, which makes the
code faster. Additionally it includes unit tests + optimizations + fixes for
the unit tests. None of these commits are extremely important, but they
would be nice to have in 4.7. May I backport them?

There is one commit ( 7414a3c38b29cb4b2c37457ca8bd1e894aab57c5 ), that I do
need to push. Indexing is broken in rc2, and the commit fixes it. It has
been tested thoroughly by me, and some people in open-suse.

I was informed, that the new policy for bugs is that they should be
committed to the 4.7 branch, and then the 4.7 branch should be merged into
master. If that is the case, then most of these commits should go into 4.7,
as merging 4.7 -> master currently creates a number of conflicts.

Additionally, I've been working on fixing a class called the
ResourceWatcher, which is our new API for monitoring changes in Nepomuk. The
class was added just in time for the feature freeze, and is quite buggy. No
one uses the ResourceWatcher right now. However, the telepathy team need the
ResourceWatcher as do the PIM folks. The current mechanism for monitoring
changes is not convenient, and slows down the entire system. Would it be
okay to backport those changes as well?

I know I'm asking for a lot, but all of these changes qualify as bug fixes.


-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/release-team/attachments/20110713/efef6ed6/attachment.htm