Backporting Nepomuk changes

[Vishesh Handa]

Since nobody has any objections. I'm going to backport all my changes
tomorrow.

Thanks

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
>> 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.
>>
>
> 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
>> 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'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
>> 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
>> _______________________________________________
>> release-team mailing list
>> release-team at kde.org
>> https://mail.kde.org/mailman/listinfo/release-team
>>
>
>
>
> --
> Vishesh Handa
>



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