On Sun, Jan 6, 2013 at 10:08 PM, Frank Reininghaus <frank7...@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
_______________________________________________ Nepomuk mailing list Nepomuk@kde.org https://mail.kde.org/mailman/listinfo/nepomuk
