Backporting Nepomuk changes
handa.vish at gmail.com
Fri Jul 15 19:23:26 CEST 2011
Since nobody has any objections. I'm going to backport all my changes
On Wed, Jul 13, 2011 at 8:40 PM, Vishesh Handa <handa.vish at gmail.com> wrote:
> Hey Sebastian
> On Wed, Jul 13, 2011 at 8:05 PM, Sebastian Kügler <sebas at kde.org> wrote:
>> 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
>> > fixed certain bugs in the ResourceMerger. The ResourceMerger is used
>> > 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
>> likely. (And easier to catch regressions). I do have to admit that
>> "refactoring" doesn't exactly sounds like post-RC material.
> I had to refactor the code in order to get the unit tests to pass. The
> earlier design was a remnant of my gsoc design from summer 2010.
>> > There is one commit ( 7414a3c38b29cb4b2c37457ca8bd1e894aab57c5 ), that I
>> > 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'll backport it tonight. ( + its unit test )
>> > 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
>> > master. If that is the case, then most of these commits should go into
>> > 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
>> 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
>> I'd say if you don't get vetoed within 2 days, please backport the changes
>> Thanks for working on making Nepomuk rock, btw :)
>> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>> release-team mailing list
>> release-team at kde.org
> Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the release-team