[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Backporting Nepomuk changes
From:       Vishesh Handa <handa.vish () gmail ! com>
Date:       2011-07-15 17:35:26
Message-ID: CAKb-1oeZpFwiZjw9jxEQcm=b6-HiecFrVsZi=85VG3Cq=8uiHw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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@gmail.com> wrote:

> Hey Sebastian
>
> On Wed, Jul 13, 2011 at 8:05 PM, Sebastian Kügler <sebas@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@kde.org
>> https://mail.kde.org/mailman/listinfo/release-team
>>
>
>
>
> --
> Vishesh Handa
>



-- 
Vishesh Handa

[Attachment #5 (text/html)]

Since nobody has any objections. I&#39;m going to backport all my changes \
tomorrow.<br><br>Thanks<br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 8:40 \
PM, Vishesh Handa <span dir="ltr">&lt;<a \
href="mailto:handa.vish@gmail.com">handa.vish@gmail.com</a>&gt;</span> wrote:<br> \
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;">Hey Sebastian <br><br><div class="gmail_quote"><div \
class="im">On Wed, Jul 13, 2011 at 8:05 PM, Sebastian Kügler <span dir="ltr">&lt;<a \
href="mailto:sebas@kde.org" target="_blank">sebas@kde.org</a>&gt;</span> wrote:<br> \
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Hi Vishesh,<br>
<div><br>
On Wednesday, July 13, 2011 16:20:01 Vishesh Handa wrote:<br>
&gt; I&#39;m a Nepomuk developer. I&#39;m requesting permission to backport a \
large<br> &gt; number commits in kde-runtime.<br>
&gt;<br>
&gt; I created a branch called &#39;nepomuk/mergerRefactoring&#39;, that optimized \
and<br> &gt; fixed certain bugs in the ResourceMerger. The ResourceMerger is used \
when<br> &gt; large amounts of data are pushed in Nepomuk, eg - Strigi indexing. \
The<br> &gt; branch refactors the code and remove a TransactionModel, which makes \
the<br> &gt; code faster. Additionally it includes unit tests + optimizations + \
fixes<br> &gt; for the unit tests. None of these commits are extremely important, \
but<br> &gt; they would be nice to have in 4.7. May I backport them?<br>
<br>
</div>Passing more unittests seems like a good idea, making real-world usage more<br>
likely. (And easier to catch regressions). I do have to admit that<br>
&quot;refactoring&quot; doesn&#39;t exactly sounds like post-RC \
material.<br></blockquote></div><div><br>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.<br>

<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt \
0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"> <div><br>
&gt; There is one commit ( 7414a3c38b29cb4b2c37457ca8bd1e894aab57c5 ), that I do<br>
&gt; need to push. Indexing is broken in rc2, and the commit fixes it. It has<br>
&gt; been tested thoroughly by me, and some people in open-suse.<br>
<br>
</div>This one should go in for sure.<br></blockquote></div><div><br>I&#39;ll \
backport it tonight. ( + its unit test )<br> <br></div><div><div></div><div \
class="h5"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt \
0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">


<div><br>
&gt; I was informed, that the new policy for bugs is that they should be<br>
&gt; committed to the 4.7 branch, and then the 4.7 branch should be merged into<br>
&gt; master. If that is the case, then most of these commits should go into 4.7,<br>
&gt; as merging 4.7 -&gt; master currently creates a number of conflicts.<br>
<br>
</div>Doesn&#39;t really matter at this point. IIRC, this policy is there as \
general<br> recommendation to do fixes in -stable and forwardport to master. Which \
way<br> your specific changes should be merged, I don&#39;t really care. (But maybe \
others<br> have good reason to do.)<br>
<div><br>
&gt; Additionally, I&#39;ve been working on fixing a class called the<br>
&gt; ResourceWatcher, which is our new API for monitoring changes in Nepomuk.<br>
&gt; The class was added just in time for the feature freeze, and is quite<br>
&gt; buggy. No one uses the ResourceWatcher right now. However, the telepathy<br>
&gt; team need the ResourceWatcher as do the PIM folks. The current mechanism<br>
&gt; for monitoring changes is not convenient, and slows down the entire<br>
&gt; system. Would it be okay to backport those changes as well?<br>
<br>
</div>I think so, yes. It&#39;s of little use if it&#39;s broken, and the risk of<br>
regressions is low.<br>
<div><br>
&gt; I know I&#39;m asking for a lot, but all of these changes qualify as bug \
fixes.<br> <br>
</div>I&#39;d say if you don&#39;t get vetoed within 2 days, please backport the \
changes you<br> propose.<br>
<br>
Thanks for working on making Nepomuk rock, btw :)<br></blockquote><div><br>:)<br> \
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt \
0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">

<font color="#888888">--<br>
sebas<br>
<br>
<a href="http://www.kde.org" target="_blank">http://www.kde.org</a> | <a \
href="http://vizZzion.org" target="_blank">http://vizZzion.org</a> | GPG Key ID: 9119 \
0EF9<br> _______________________________________________<br>
release-team mailing list<br>
<a href="mailto:release-team@kde.org" target="_blank">release-team@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/release-team" \
target="_blank">https://mail.kde.org/mailman/listinfo/release-team</a><br> \
</font></blockquote></div></div></div><br><br clear="all"><br>-- <br><font \
color="#888888"><font color="#999999">Vishesh Handa</font><br> \
</font></blockquote></div><br><br clear="all"><br>-- <br><font \
color="#999999">Vishesh Handa</font><br>



_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic