<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 23, 2012 at 8:01 PM, Frank Reininghaus <span dir="ltr"><<a href="mailto:frank78ac@googlemail.com" target="_blank">frank78ac@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree with Sebastian - the freezes are there for a reason. I<br>
appreciate all offers to help with testing in the remaining time until<br>
the 4.10.0 release, but if that was really enough to make sure that<br>
there are no regressions, then we could just drop the betas and<br>
release a single RC in the future.</blockquote><div><br></div><div>That's making a very generalized statement, and ignoring the current situation. Please look at how much the code has changed from the 4.9. I'm not advocating shipping something written from scratch this late into the schedule.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> However, past experience shows that<br>
the user feedback that we get for the 4 unstable releases before each<br>
4.x.0 release helps to find many annoying bugs, but is still not<br>
enough to prevent that a few regressions make it into 4.x.0. Yes, we<br>
do have 4.x.1 and further bug fix releases, but in the end, users just<br>
don't like it when there are new bugs in 4.x.0, and I perfectly<br>
understand that.</blockquote><div><br></div><div>Users always dislike bugs. We all understand that.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The angry bug reports would end up in my inbox, and<br>
the reporters would even be right because I would be responsible for<br>
any problems if I approved the use of code that has not seen any wide<br>
testing before RC 2.<br></blockquote><div><br></div><div>That's for the general case.<br><br></div><div>You have to look at exactly what I'm proposing and how much the code has changed. The answer is not much.<br>
<br></div><div>I understand that almost all code have bugs, but you should at least look at the uses cases of this widget, and if my patch satisfies all of the use cases you can think of.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Therefore, I think that using the new widget in Dolphin should not<br>
happen before KDE 4.11. Users who really want to use it earlier can<br>
just build Dolphin from source and apply the patch (which is not that<br>
hard even if you do not use a source-based distro, just install the<br>
kdelibs headers and then perform a few simple steps).<br></blockquote><div><br></div><div>This rules out about 99% of the users.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I also thought again about Vishesh's argument that he would "have to<br>
spend 2-3 days (maybe even more?)" if we do not use the new widget in<br>
KDE 4.10, and I must say that I do not understand this at all. How can<br>
can using the old widget in KDE 4.10 make the user experience worse<br>
than in KDE 4.9 if he does not spend 2-3 days hacking on the old code?<br></blockquote><div><br></div><div>You loose consistency. If a file is now indexed by Nepomuk it will show different metadata in the Information Panel than if the file was not indexed, and the user selected the file.<br>
<br></div><div>Current bugs visible via the KFileMetadataWidget -<br><br>* <a href="https://bugs.kde.org/show_bug.cgi?id=257438" target="_blank">https://bugs.kde.org/show_bug.cgi?id=257438</a> (crash)<br>* <a href="https://bugs.kde.org/show_bug.cgi?id=270739" target="_blank">https://bugs.kde.org/show_bug.cgi?id=270739</a> (crash)<br>
* <a href="https://bugs.kde.org/show_bug.cgi?id=270739" target="_blank">https://bugs.kde.org/show_bug.cgi?id=270739</a> (crash)<br>* <a href="https://bugs.kde.org/show_bug.cgi?id=281342" target="_blank">https://bugs.kde.org/show_bug.cgi?id=281342</a> (crash)<br>
* <a href="https://bugs.kde.org/show_bug.cgi?id=160157" target="_blank">https://bugs.kde.org/show_bug.cgi?id=160157</a><br>* <a href="https://bugs.kde.org/show_bug.cgi?id=285039" target="_blank">https://bugs.kde.org/show_bug.cgi?id=285039</a><br>
* <a href="https://bugs.kde.org/show_bug.cgi?id=311796" target="_blank">https://bugs.kde.org/show_bug.cgi?id=311796</a><br>* <a href="https://bugs.kde.org/show_bug.cgi?id=303875" target="_blank">https://bugs.kde.org/show_bug.cgi?id=303875</a><br>
* <a href="https://bugs.kde.org/show_bug.cgi?id=311201" target="_blank">https://bugs.kde.org/show_bug.cgi?id=311201</a><br>
<br></div><div>Some of these bugs are already fixed in nepomuk-core. Other bugs can easily be fixed in nepomuk-core and be properly tested. They cannot be properly tested in kdelibs/nepomuk. The code base is too different now, and it would require too much effort.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best regards<br>
<span><font color="#888888">Frank<br>
</font></span><div><div>_______________________________________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/listinfo/nepomuk</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br>
</div></div>