Exception for Dolphin - KFileMetadataWidget

Tue Jan 8 07:18:13 UTC 2013

On Sun, Jan 6, 2013 at 10:08 PM, Frank Reininghaus <frank78ac at googlemail.com
> wrote:

>
> 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 :-)
>

Submitted - https://git.reviewboard.kde.org/r/108236/

> >> 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.
>

Done

>
> >> 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.
>

Thanks

>
> >> 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
>
>
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.

> 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 understand.

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.

>
> >> 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!
>

Thank you.

>
> > 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.
>

Great. Cause we have lots to do.

-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130108/e8bb01d8/attachment.html>