Exception for Dolphin - KFileMetadataWidget

[Albert Astals Cid]

El Dissabte, 22 de desembre de 2012, a les 10:37:00, Frank Reininghaus va 
escriure:
> Hi everyone,

Hi

> 2012/12/21 Albert Astals Cid:
> > El Divendres, 21 de desembre de 2012, a les 16:27:17, Vishesh Handa va
> > 
> > escriure:
> >> Hello release team
> >> 
> >> As most of you must know for KDE 4.9, a new package nepmuk-core was
> >> released, and with 4.10 we are now releasing nepomuk-widgets. The
> >> nepomuk-widgets initially just contained the Tagging and Rating widgets,
> >> which were adapted from kdelibs/nepomuk/ui. I use the word "adapted"
> >> cause
> >> their internals were ported to the new asynchronous APIs (which was the
> >> reason nepomuk-core was created)
> >> 
> >> One of the primary ways users tag and rate files is through the
> >> information
> >> panel in Dolphin. The main widget in this panel is the
> >> KFileMetadataWidget
> >> (kdelibs/kio/kfile/*). This widget has many problems -
> >> 
> >> * Uses the old Nepomuk Resource API from kdelibs - very buggy
> >> * Uses the old Nepomuk widgets from kdelibs - slower and not maintained
> >> * Had a multi-process architecture which involved spawning a new process
> >> which provided the Nepomuk / Strigi ** data. This was done cause Strigi
> >> is
> >> known to crash a lot.
> >> * Cause of this multi-process architecture it was very slow - specially
> >> on
> >> the Nepomuk side cause it would re-create the caches each time the
> >> process
> >> was run. This was especially wasteful because Dolphin itself uses Nepomuk
> >> and would have those caches. (The caches are not cross-application)
> >> * Hacking on the widget was hard - Its entire architecture is quite
> >> convoluted.
> >> 
> >> I wanted to fix this with 4.10, so I copied most of the widget to
> >> nepomuk-widgets and named it Nepomuk2::FileMetadataWidget. This "new"
> >> widget was added in the feature plan [1]. It was never marked as
> >> completed
> >> cause it had some bugs, which I did not have the time to fix. It was
> >> however, still merged before the hard feature freeze.
> >> 
> >> I did not submit my patch to use this widget in Dolphin, as it had some
> >> bugs, and I did not want to spoil Dolphin's experience. In hind-sight
> >> maybe
> >> I should have submitted it, and gotten all the bug reports.
> >> 
> >> Fast forwarding to present time
> >> ----------------------------------------------
> >> 
> >> I finally squashed the last of the bugs in the widget, and made it
> >> support
> >> displaying indexing results even when the file was not indexed or Nepomuk
> >> is disabled. The old KFileMetadataWidget had the same capability - It
> >> used
> >> Strigi, while we use the new file indexer that I've been working on.
> >> 
> >> I would like to use this new widget in dolphin for 4.10. I was told to
> >> ask
> >> for an exception from the release team. We still have one more release
> >> candidate to go, so it should get adequate testing, if not the full
> >> amount.
> >> 
> >> Other advantages -
> >> 
> >> * It is a LOT faster - and it feels like it (Patch attached, if you want
> >> to
> >> try it out)
> >> * Easier to maintain
> >> * Uses the Nepomuk2 widgets which are actively maintained, and will thus
> >> get the required bug fixes. They have been some bugs filed against
> >> Dolphin
> >> and its tagging behaviour, fixing this would be quite hard in
> >> kdelibs/Nepomuk, also I don't want to mess with that code base which
> >> barely
> >> gets tested any more.
> >> * Since Dolphin also uses Nepomuk2, and the new widget does not spawn a
> >> new
> >> process for the Nepomuk data, it can re-use the already filled caches.
> >> * This gives a much better experience even when Nepomuk is disabled.
> >> * This new widget's internal architecture is a lot better, and it's easy
> >> to
> >> modify - So it's easy to improve.
> >> 
> >> If we do not ship this new widget, I'll have to clean up the
> >> KFileMetadataWidget cause it shows a lot of ugly data like "Resource
> >> Created", arguably this isn't very hard. However it is not something I
> >> want
> >> to do. Ditto for kdelibs/nepomuk/*.
> >> 
> >> So, may I merge my patch into kde-baseapps 4.10? It will get tested more
> >> thoroughly in RC2.
> > 
> > What's the opinion of the Dolphin maintainer?
> 
> first of all, I really appreciate Vishesh's work. I see that the new
> widget has lots of benefits that many users will appreciate, and maybe
> it would be nice to see it in KDE 4.10 even though I feel a bit
> uncomfortable about using lots of new code that would only be tested
> by a large number of people in RC2 (as I already said in [1]).
> 
> Seeing that I'm not the only one who feels uneasy about this (see
> Sebastian's mail) has made my concerns worse.
> 
> If many people thought that the benefits of the new widget outweigh
> the risks, I would say "let's merge it" - I don't want to be blamed by
> future users of KDE 4.10 for holding back useful things if there is no
> good reason for it. But at the moment, it seems that there are more
> people who are worried about the risks, so I feel that it should
> better wait until KDE 4.11.

To be honest I think the release-team is not a good place to find people with 
an opinion over if "the benefits of the new widget outweigh the risks", since 
the "Dolphin knowledge" of people that are part of the release-team is 
probably small. 

I think it should be the people working on Dolphin (and ultimately Frank as 
maintaier) that decide and then they say "We think this should be in" and then 
explain to the release-team the risks and benefits and then we would decide 
(which I understand it would basically mean agree)

But then we find that not even Frank is convinced, so what i think Vishesh you 
should try to do is convince Frank that it's a better way for the future.

Frank, i guess the question you should make yourself (and try to get all the 
people with Dolphin knowledge to answer) is: In 2 months time (i.e. around 
4.10.1), what will be better for my users, keeping the current "unmaintained" 
code or using the new one?

Cheers,
  Albert

> 
> Best regards,
> Frank
> 
> [1] http://lists.kde.org/?l=nepomuk&m=135601861024534&w=2
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team