<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jan 6, 2013 at 10:08 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"><br>What I found hackish was to make Nepomuk2::FileMetaDataWidget a<br>
typedef for the old widget from kdelibs. One can probably achieve this<br>
in a cleaner way using #ifdef HAVE_NEPOMUK.<br>
<br>
Your patch will certainly be welcome :-)<br></blockquote><div><br></div><div>Submitted - <a href="https://git.reviewboard.kde.org/r/108236/" target="_blank">https://git.reviewboard.kde.org/r/108236/</a><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">


<div>>> Yes, it's a hack, but it could be made<br>
>> slightly less hackish and include the case that nepomuk-core is there,<br>
>> but nepomuk-widgets isn't, and then everything would at least build.<br>
><br>
><br>
> nepomuk-widget and nepomuk-core are both a part of KDE SC 4.10, so I don't<br>
> think there should be a problem of only one of them existing. Even PIM<br>
> depends on nepomuk-widgets.<br>
<br>
</div>OK, but then the build system should set HAVE_NEPOMUK only if core AND<br>
widgets are found.<br></blockquote><div><br></div><div>Done<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">
<div><div><br>
>> The alternative would be to make both nepomuk-core AND nepomuk-widgets<br>
>> hard dependencies for Dolphin. In the long term, this might even be<br>
>> something to think about because we could then also remove all the<br>
>> HAVE_NEPOMUKs from the source (even though the feedback that I got<br>
>> shows that some users like to build Dolphin without Nepomuk, possibly<br>
>> because they are not using a full KDE desktop and don't want to pull<br>
>> in too many dependencies), but adding new hard dependencies this late<br>
>> in the release process is wrong IMHO.<br>
><br>
><br>
> Of course.<br>
><br>
>><br>
>> The third option (revert the patch) is something that even I am not in<br>
>> favour of at this point, now that the release delay for the new widget<br>
>> has been announced to the public.<br>
>><br>
>> Now people will probably ask why I did not notice this problem before.<br>
>> Simple answer: I hadn't looked at the patch at all. I was quite busy<br>
>> around Christmas and New Year, mostly with real life issues, and saw<br>
>> no point in reviewing something that I did not want in KDE 4.10 at<br>
>> all, and when the extra RC was announced, I only had a 4" screen,<br>
>> which is not exactly suitable for looking at code, and little<br>
>> motivation to spend my holiday working on this, because I was quite<br>
>> frustrated by how the discussion went.<br>
>><br>
>> And to answer the next question: no, I never said that Vishesh should<br>
>> ask the release-team about including this in KDE 4.10. Even though<br>
>> Vishesh seems to have misunderstood me, my earlier messages<br>
>><br>
>> <a href="http://lists.kde.org/?l=kfm-devel&m=135601666623890&w=2" target="_blank">http://lists.kde.org/?l=kfm-devel&m=135601666623890&w=2</a><br>
>> <a href="http://lists.kde.org/?l=kfm-devel&m=135601860424533&w=2" target="_blank">http://lists.kde.org/?l=kfm-devel&m=135601860424533&w=2</a><br>
>><br>
>> only mention the release team in response to the statements "At the<br>
>> end, it's your call" and "Anyway, it's your choice". What I meant was<br>
>> that even if I agreed (and I listed enough good reasons for not<br>
>> agreeing IMHO), the change still couldn't go in unless the release<br>
>> team agreed as well.<br>
>><br>
>> So I was quite surprised by Vishesh's request here, but I still tried<br>
>> to write a polite answer that shows appreciation for the work of<br>
>> others, because that's how I like to communicate (even though I now<br>
>> see that simply saying "no" might have been better):<br>
>><br>
>> <a href="http://mail.kde.org/pipermail/release-team/2012-December/006624.html" target="_blank">http://mail.kde.org/pipermail/release-team/2012-December/006624.html</a><br>
>><br>
>> But at least my later message was clear, I think:<br>
>><br>
>> <a href="http://mail.kde.org/pipermail/release-team/2012-December/006630.html" target="_blank">http://mail.kde.org/pipermail/release-team/2012-December/006630.html</a><br>
>><br>
><br>
> Perhaps I've been a little short sighted over here.<br>
><br>
> I really wanted to get the widget in cause of its very obvious benefits<br>
> which I've mentioned earlier. Maybe cause of that I overlooked your firm<br>
> "no" as a "no - cause you're too late and we have rules". I thought that if<br>
> the rules were the only reason, an exception granted by the release team<br>
> would be alright.<br>
><br>
> Even in the later email - I mostly focused on how you felt that it wouldn't<br>
> get tested enough. The email mentioned how there would be excessive bug<br>
> reports and angry emails from users. I thought that the additional RC and<br>
> increased awareness addressed those concerns.<br>
><br>
> I didn't think that you would still disagree after the issues raised had<br>
> been addressed. I was obviously wrong.<br>
><br>
> If possible, I would like to know why you still felt that this shouldn't<br>
> have gone in? Is it just cause of the lack of testing?<br>
<br>
</div></div>I see that the new widget has lots of benefits. But every new feature<br>
has benefits, or it wouldn't be worth calling it a feature. OTOH,<br>
every new feature might bring serious new bugs, which is why there is<br>
the betas and RCs for testing. Now if the procedure is changed, I<br>
think there should be good reasons why the "usefulness of the new<br>
feature" vs "risk of new bugs" ratio can be expected to be extremely<br>
good.<br>
<br>
I know that you put a lot of work into the new widget. You deserve to<br>
be proud of it, and I understand that you wanted to ship it to users<br>
ASAP. But I might be biased a bit to the other sider because I still<br>
remember the times when we got a couple of Dolphin crash reports a day<br>
which were due to Nepomuk (no, not all of them were DBus' fault).<br>
Based on these experiences and the fact that Nepomuk is certainly a<br>
very useful, but also a quite complex piece of software, I might tend<br>
to be a bit careful about using new Nepomuk code that hasn't seen wide<br>
testing yet so late in the release cycle.<br>
<br>
But now it's clear that the change will be in KDE 4.10, so let's try<br>
to make it work as good as we can.<br></blockquote><div><br></div><div>Thanks<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">
<div><br>
>> Please note that I'm not blaming anyone for anything here, I'm just<br>
>> trying to answer the obvious question "why did the maintainer not<br>
>> notice this before?" in advance.<br>
>><br>
>> I'm sorry if this message is considered offensive, but I'm seriously<br>
>> fed up with the way Nepomuk repeatedly broke things in the last years<br>
>> and caused extra work for everyone.<br>
><br>
> Last years?<br>
<br>
</div>I was thinking of issues like the introduction of SDO as a hard<br>
dependency without any prior announcement, which caused lots of pain<br>
for everyone building KDE from source:<br>
<br>
<a href="http://thread.gmane.org/gmane.comp.kde.cvs/845288/focus=62296" target="_blank">http://thread.gmane.org/gmane.comp.kde.cvs/845288/focus=62296</a><br>
<br></blockquote><div><br></div><div>Interesting. I didn't know about this. I started contributing to Nepomuk sometime in early 2010. Though since then we have had another SDO related goof-up.<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">


There were more occasions where Nepomuk-related things caused trouble<br>
for other developers and/or packagers, one could certainly find out by<br>
digging in the mailing list archives. I'll do that if there is some<br>
interest.<br>
<br>
These issues were not your fault, of course, but when things like<br>
these happen, people who are not involved with Nepomuk might start to<br>
wonder if enough attention is given to the possible consequences that<br>
any changes in and around Nepomuk will have for developers of other<br>
parts of KDE, packagers, and users.<br></blockquote><div><br></div><div>I understand.<br><br></div><div>For this particular release I've tried to focus less on - "This is technologically superior" and just improve the "user experience". I hope it turns out okay.<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">
<div><br>
>> I'm still willing to collaborate<br>
>> constructively with Nepomuk and Vishesh in particular, but IMHO, the<br>
>> way Nepomuk interacts with the rest of the KDE community has to<br>
>> change.<br>
><br>
><br>
> Please note that I've only recently (last 6 months) taken up maintainer-ship<br>
> of Nepomuk. I thought I was doing a decent job - maybe I've only been<br>
> focusing on the technical aspects. It would be nice if someone could gently<br>
> prod me in the right direction.<br>
<br>
</div>I think that you are doing a good job!<br></blockquote><div><br></div><div>Thank you.<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">


<div><br>
> For one - I will try to abide by the higher quality standards and get<br>
> everything in well before the release date.<br>
<br>
</div>Perfect!<br>
<div><br>
> This entire process of getting<br>
> in the new widget has been fairly eventful, and while it might be an<br>
> improvement for the users, it has caused a lot of strife between the<br>
> developers.<br>
<br>
</div>Yes, but for me the issue is resolved now (except for the build<br>
system), so I'm looking forward to a fruitful collaboration in the<br>
future.<br></blockquote><div><br></div><div>Great. Cause we have lots to do.</div></div><br><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br>
</div></div>