Backporting Nepomuk changes

[Sebastian Kügler]

Hi Vishesh,

On Wednesday, July 13, 2011 16:20:01 Vishesh Handa wrote:
> 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?

Passing more unittests seems like a good idea, making real-world usage more 
likely. (And easier to catch regressions). I do have to admit that 
"refactoring" doesn't exactly sounds like post-RC material.

> 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.

This one should go in for sure.

> 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.

Doesn't really matter at this point. IIRC, this policy is there as general 
recommendation to do fixes in -stable and forwardport to master. Which way 
your specific changes should be merged, I don't really care. (But maybe others 
have good reason to do.)

> 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 think so, yes. It's of little use if it's broken, and the risk of 
regressions is low.

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

I'd say if you don't get vetoed within 2 days, please backport the changes you 
propose.

Thanks for working on making Nepomuk rock, btw :)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9