Exception for Dolphin - KFileMetadataWidget

Sun Jan 6 16:38:09 UTC 2013

Hi Vishesh,

thanks for your detailed reply!

2013/1/6 Vishesh Handa:
>
> On Sun, Jan 6, 2013 at 2:21 PM, Frank Reininghaus
> wrote:
>>
>> Hi everyone,
>
>
> Hey Frank
>
>>
>> > This should be fixed.
>>
>> Actually, I decided to not care about the entire Nepomuk issue any
>> more after nobody cared about my repeated statement that I do not want
>> this change in KDE 4.10. But now that the build is broken, it seems
>> that I have no choice.
>>
>>
>> I think that there are two different problems now. The build fails if:
>>
>> 1) nepomuk-core is found (such that HAVE_NEPOMUK is set in Dolphin),
>> but nepomuk-widgets isn't, or if
>> 2) nepomuk-core is not found, such that HAVE_NEPOMUK is not set.
>>
>> I got e-mails from users about issue 2, including a user-supplied
>> patch to fix it (see attachment). It replaces the new
>> Nepomuk2::FileMetaDataWidget by the old KFileMetaDataWidget if
>> HAVE_NEPOMUK is not defined.
>
> I wrote a patch to do the same thing yesterday. I still haven't put it up on
> the review board. Is the solution really that hacky? I can't think of a
> better alternative.

What I found hackish was to make Nepomuk2::FileMetaDataWidget a
typedef for the old widget from kdelibs. One can probably achieve this
in a cleaner way using #ifdef HAVE_NEPOMUK.

Your patch will certainly be welcome :-)

>> Yes, it's a hack, but it could be made
>> slightly less hackish and include the case that nepomuk-core is there,
>> but nepomuk-widgets isn't, and then everything would at least build.
>
>
> nepomuk-widget and nepomuk-core are both a part of KDE SC 4.10, so I don't
> think there should be a problem of only one of them existing. Even PIM
> depends on nepomuk-widgets.

OK, but then the build system should set HAVE_NEPOMUK only if core AND
widgets are found.

>> The alternative would be to make both nepomuk-core AND nepomuk-widgets
>> hard dependencies for Dolphin. In the long term, this might even be
>> something to think about because we could then also remove all the
>> HAVE_NEPOMUKs from the source (even though the feedback that I got
>> shows that some users like to build Dolphin without Nepomuk, possibly
>> because they are not using a full KDE desktop and don't want to pull
>> in too many dependencies), but adding new hard dependencies this late
>> in the release process is wrong IMHO.
>
>
> Of course.
>
>>
>> The third option (revert the patch) is something that even I am not in
>> favour of at this point, now that the release delay for the new widget
>> has been announced to the public.
>>
>> Now people will probably ask why I did not notice this problem before.
>> Simple answer: I hadn't looked at the patch at all. I was quite busy
>> around Christmas and New Year, mostly with real life issues, and saw
>> no point in reviewing something that I did not want in KDE 4.10 at
>> all, and when the extra RC was announced, I only had a 4" screen,
>> which is not exactly suitable for looking at code, and little
>> motivation to spend my holiday working on this, because I was quite
>> frustrated by how the discussion went.
>>
>> And to answer the next question: no, I never said that Vishesh should
>> ask the release-team about including this in KDE 4.10. Even though
>> Vishesh seems to have misunderstood me, my earlier messages
>>
>> http://lists.kde.org/?l=kfm-devel&m=135601666623890&w=2
>> http://lists.kde.org/?l=kfm-devel&m=135601860424533&w=2
>>
>> only mention the release team in response to the statements "At the
>> end, it's your call" and "Anyway, it's your choice". What I meant was
>> that even if I agreed (and I listed enough good reasons for not
>> agreeing IMHO), the change still couldn't go in unless the release
>> team agreed as well.
>>
>> So I was quite surprised by Vishesh's request here, but I still tried
>> to write a polite answer that shows appreciation for the work of
>> others, because that's how I like to communicate (even though I now
>> see that simply saying "no" might have been better):
>>
>> http://mail.kde.org/pipermail/release-team/2012-December/006624.html
>>
>> But at least my later message was clear, I think:
>>
>> http://mail.kde.org/pipermail/release-team/2012-December/006630.html
>>
>
> Perhaps I've been a little short sighted over here.
>
> I really wanted to get the widget in cause of its very obvious benefits
> which I've mentioned earlier. Maybe cause of that I overlooked your firm
> "no" as a "no - cause you're too late and we have rules". I thought that if
> the rules were the only reason, an exception granted by the release team
> would be alright.
>
> Even in the later email - I mostly focused on how you felt that it wouldn't
> get tested enough. The email mentioned how there would be excessive bug
> reports and angry emails from users. I thought that the additional RC and
> increased awareness addressed those concerns.
>
> I didn't think that you would still disagree after the issues raised had
> been addressed. I was obviously wrong.
>
> If possible, I would like to know why you still felt that this shouldn't
> have gone in? Is it just cause of the lack of testing?

I see that the new widget has lots of benefits. But every new feature
has benefits, or it wouldn't be worth calling it a feature. OTOH,
every new feature might bring serious new bugs, which is why there is
the betas and RCs for testing. Now if the procedure is changed, I
think there should be good reasons why the "usefulness of the new
feature" vs "risk of new bugs" ratio can be expected to be extremely
good.

I know that you put a lot of work into the new widget. You deserve to
be proud of it, and I understand that you wanted to ship it to users
ASAP. But I might be biased a bit to the other sider because I still
remember the times when we got a couple of Dolphin crash reports a day
which were due to Nepomuk (no, not all of them were DBus' fault).
Based on these experiences and the fact that Nepomuk is certainly a
very useful, but also a quite complex piece of software, I might tend
to be a bit careful about using new Nepomuk code that hasn't seen wide
testing yet so late in the release cycle.

But now it's clear that the change will be in KDE 4.10, so let's try
to make it work as good as we can.

>> Please note that I'm not blaming anyone for anything here, I'm just
>> trying to answer the obvious question "why did the maintainer not
>> notice this before?" in advance.
>>
>> I'm sorry if this message is considered offensive, but I'm seriously
>> fed up with the way Nepomuk repeatedly broke things in the last years
>> and caused extra work for everyone.
>
> Last years?

I was thinking of issues like the introduction of SDO as a hard
dependency without any prior announcement, which caused lots of pain
for everyone building KDE from source:

http://thread.gmane.org/gmane.comp.kde.cvs/845288/focus=62296

There were more occasions where Nepomuk-related things caused trouble
for other developers and/or packagers, one could certainly find out by
digging in the mailing list archives. I'll do that if there is some
interest.

These issues were not your fault, of course, but when things like
these happen, people who are not involved with Nepomuk might start to
wonder if enough attention is given to the possible consequences that
any changes in and around Nepomuk will have for developers of other
parts of KDE, packagers, and users.

>> I'm still willing to collaborate
>> constructively with Nepomuk and Vishesh in particular, but IMHO, the
>> way Nepomuk interacts with the rest of the KDE community has to
>> change.
>
>
> Please note that I've only recently (last 6 months) taken up maintainer-ship
> of Nepomuk. I thought I was doing a decent job - maybe I've only been
> focusing on the technical aspects. It would be nice if someone could gently
> prod me in the right direction.

I think that you are doing a good job!

> For one - I will try to abide by the higher quality standards and get
> everything in well before the release date.

Perfect!

> This entire process of getting
> in the new widget has been fairly eventful, and while it might be an
> improvement for the users, it has caused a lot of strife between the
> developers.

Yes, but for me the issue is resolved now (except for the build
system), so I'm looking forward to a fruitful collaboration in the
future.

Thanks and best regards,
Frank