Backporting Nepomuk changes

[Vishesh Handa]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/release-team/attachments/20110713/8f87dbbe/attachment.htm