Backporting Nepomuk changes
sebas at kde.org
Wed Jul 13 16:35:27 CEST 2011
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
Thanks for working on making Nepomuk rock, btw :)
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
More information about the release-team