[prev in list] [next in list] [prev in thread] [next in thread]
List: kfm-devel
Subject: Re: Exception for Dolphin - KFileMetadataWidget
From: Vishesh Handa <me () vhanda ! in>
Date: 2012-12-21 13:33:45
Message-ID: CAOPTMKAUR+G=C9p-rk+WO+73Er4p2aax2pQ__XJsq3PCPzS4wA () mail ! gmail ! com
[Download RAW message or body]
On Fri, Dec 21, 2012 at 6:32 PM, Sebastian Kügler <sebas@kde.org> wrote:
> On Friday, December 21, 2012 16:27:17 Vishesh Handa wrote:
> > So, may I merge my patch into kde-baseapps 4.10? It will get tested more
> > thoroughly in RC2.
>
> I'm very uneasy with merging something this big and intrusive into 4.10 at
> this point. I also don't see why it has to go into 4.10, sure, it's all
> nice,
> but certainly not critical, especially since ...
>
It means shipping un-maintained code which is slow and has documented bugs.
I personally think it is better to ship actively maintained code where
there is a developer to fix any bugs (if they should be), than something
old and stale.
> Would it not cause functional regressions, since the old indexer would
> index
> many more file types than the new indexing services in nepomuk-core?
>
Just so that everyone is clear. We are talking about the case when Nepomuk
is disabled / the file has not metadata in Nepomuk. In that case,
KFileMetadataInfo used to temporarily index the file via strgi, and display
the results. The Nepomuk2::FileMetadata widget does the same, but it uses
the nepomuk indexer, and not strigi.
This has nothing to do with the actual file indexing.
Regarding functional regressions - Not really. The only big difference is
office based formats, which my indexer still doesn't target. I'm still
working on that, I should have it ready by RC2. We also handle pdfs which
strigi does not.
Also, considering that amount of testing Nepomuk is going through cause of
the new indexer, I'm fairly certain we will have greater coverage than
Strigi. There is also the issue of stability and speed.
--
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>
--
Vishesh Handa
[Attachment #3 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, \
Dec 21, 2012 at 6:32 PM, Sebastian Kügler <span dir="ltr"><<a \
href="mailto:sebas@kde.org" target="_blank">sebas@kde.org</a>></span> wrote:<br> \
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">On Friday, December 21, 2012 16:27:17 Vishesh \
Handa wrote:<br> > So, may I merge my patch into kde-baseapps 4.10? It will get \
tested more<br> > thoroughly in RC2.<br>
<br>
</div>I'm very uneasy with merging something this big and intrusive into 4.10 \
at<br> this point. I also don't see why it has to go into 4.10, sure, it's \
all nice,<br> but certainly not critical, especially since \
...<br></blockquote><div><br></div><div>It means shipping un-maintained code which is \
slow and has documented bugs. I personally think it is better to ship actively \
maintained code where there is a developer to fix any bugs (if they should be), than \
something old and stale.<br> <br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
Would it not cause functional regressions, since the old indexer would index<br>
many more file types than the new indexing services in \
nepomuk-core?<br></blockquote><div><br></div><div>Just so that everyone is clear. We \
are talking about the case when Nepomuk is disabled / the file has not metadata in \
Nepomuk. In that case, KFileMetadataInfo used to temporarily index the file via \
strgi, and display the results. The Nepomuk2::FileMetadata widget does the same, but \
it uses the nepomuk indexer, and not strigi.<br> <br></div><div>This has nothing to \
do with the actual file indexing.<br></div><div><br>Regarding functional regressions \
- Not really. The only big difference is office based formats, which my indexer still \
doesn't target. I'm still working on that, I should have it ready by RC2. We \
also handle pdfs which strigi does not.<br> <br></div><div>Also, considering that \
amount of testing Nepomuk is going through cause of the new indexer, I'm fairly \
certain we will have greater coverage than Strigi. There is also the issue of \
stability and speed.<br> <br><br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <span \
class="HOEnZb"><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> </font></span></blockquote></div><br><br clear="all"><br>-- <br><span \
style="color:rgb(192,192,192)">Vishesh Handa</span><br> </div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic