Re: Re: [Nepomuk] Nepomuk - Moving away from Strigi
On Monday 08 October 2012 at 22:26:30, Martin Gräßlin wrote: > Neither Kevin (Fedora), Scott (Kubuntu) nor Adrian (SUSE) came up with the > rules, they are just pointing out the policies. While I do not agree with > their policies I can kind of understand it. > > What everybody can do is to bring the question back to the distributions > that they might reconsider the situation and bringing back the feedback > that Upstream really wants to have working multimedia in the downstream. > > Though especially for the distributions situated in the USA I have little > hope that they might change anything. The patent system there is extremely > broken and there is quite a difference between knowing that the software > breaks patents or some bogous IP claims like SCO. > > We all know that situation and we won't change it here on kde-devel. I'd > love to do so, but it won't happen :-( > > So let's all calm down and work on good solutions :-) The best solution I can offer is: if at all possible, please (pretty please) DO NOT use FFmpeg (directly), use GStreamer. There are 4 APIs you can use to use GStreamer in your application: * Phonon (with Phonon-GStreamer, which is the default in most distributions). The highest-level API, suitable for simple playback, not so much for other tasks. * QtMobility Multimedia. Listed for completeness, probably not ideal for KDE applications. Also high-level. * QtGStreamer. Lower-level Qt bindings for GStreamer. More flexible. * GStreamer directly. C/GObject API. Lowest-level, but not as low-level as FFmpeg. ;-) If even QtGStreamer does not do what you want, try this one. Now I don't know whether GStreamer is suitable for the Nepomuk indexing task which started this thread, but e.g. for the Amarok transcoding and fingerprinting, it could definitely be used instead of the FFmpeg-based code we have now (see sound-converter (the GNOME one, not soundKonverter) for an example of how to use GStreamer for transcoding, transcoding is actually one of the things it can do well). Thumbnailing is also something which could and should be done using GStreamer rather than FFmpeg as ffmpegthumbnailer does. GStreamer helps us in several ways: * GStreamer is modular, so distros can ship only the codecs they feel safe and others can be added as plugins. (FFmpeg, on the other hand, links all the codecs into a single monolithic shared library.) * GStreamer supports system decoding libraries for many formats. In particular, most unencumbered codecs can be decoded without depending on the monolithic FFmpeg. This approach also encourages code sharing rather than reinventing the wheel as FFmpeg loves to do. * GStreamer supports FFmpeg (or actually Libav these days) codecs as one of the many plugins. * GStreamer upstream actually cares about the legal issues and already classifies the stable codecs into "good" and "ugly". (The less-proven "bad" ones, on the other hand, are not classified by upstream and are split into 3 pieces in Fedora and RPM Fusion: free and patent-free, free but patent- encumbered and outright non-free. But that's just a matter of auditing the plugins and splitting them, interested third parties can look at our split.) * If everything uses GStreamer, the user only has to add the "evil" codecs once for all apps. (And there's even a codec auto-installation feature, though admittedly that will only work if the repository containing the codec is already configured, so it's not a magic bullet.) If, on the other hand, we go with the alternative solution of having FFmpeg-based plugins for everything, sure, that also solves our problem (as long as they're really plugins, not compile-time options like Amarok's fingerprinting!), but it means the user has to install a lot of *-ffmpeg packages to get everything working. So in short, if you want multimedia to "just work" in your software, use GStreamer! Kevin Kofler >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [Nepomuk] Nepomuk - Moving away from Strigi
On Monday 08 October 2012 at 07:38:43, Eric Hameleers wrote: > Having hard requirements on ffmpeg for your nepomuk indexer would not > be appreciated by us. Making ffmpeg an optional dependency would be > better (but will cripple the indexer seriously). I think the best > solution would be to allow for an optional static binding of ffmpeg > libraries. Please no! If you bundle FFmpeg, you force us to ship repackaged tarballs (something we really don't like to do) with the bundled FFmpeg removed: https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code We cannot ship FFmpeg in Fedora in any form, not even in the source RPMs. Not to mention all the other problems with bundled libraries in general: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries Kevin Kofler >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [Nepomuk] Nepomuk - Moving away from Strigi
On Monday 08 October 2012 at 15:59:12, Aleix Pol wrote:
> In any case, I'm unsure that KDE can shine without ffmpeg.
It can, and it must. FFmpeg (or Libav which is basically the same thing) is
not acceptable for Fedora and will not be in Fedora any time soon. (Maybe in
something like 20 years when all the current multimedia patents expire, but by
then there will probably be new codecs with new patents.)
Decoding needs to be done using GStreamer.
Kevin Kofler
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [Nepomuk] Nepomuk - Moving away from Strigi
On Monday 08 October 2012 at 16:03:26, todd rme wrote: > What do you mean by "separate repository"? Do you mean people would > be able to build and install the plugins independently of > nepomuk-core? Certainly for the legally questionable ones this would > be nice. For us in Fedora, this would be not just nice, but REQUIRED. We cannot ship anything depending on FFmpeg in Fedora. So it's either shipping the offending indexers in RPM Fusion in a separate package (which will obviously NOT be installed by default, we cannot install things by default which are not in Fedora proper) or not shipping them at all. Now ideally you wouldn't depend on FFmpeg at all! I especially don't understand why you need an AV decoding library to do indexing. Kevin Kofler >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: No more release schedules.
On Friday 10 June 2011, Scott Kitterman wrote: > Kevin Kofler wrote: > >OK, since a lot of context apparently got lost during the message > >passing, let > >me just state my (personal) position clearly: > > > >What I think is acceptable: > >* Module X wants feature Y, which is non-invasive and well-tested and > >does not > >change the user experience nor the user interface in a significant way > >(for > >those not using the new feature), backported and released together with > >KDE SC 4.n.x. > > This would mean Kubuntu would not be able to ship KDE point releases as > post-release updates, which I would find very unfortunate. The rest I > agree with. Are your policies that anal? Sigh… :-( I don't really see what everyone's problem is with a feature which does not disrupt the user experience in any way. It helps users and doesn't hurt anyone. These are the current Fedora policies: https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases which some of us (including me) are already complaining about as too strict. Yet the "not introduce features" part is qualified by "particularly when those features would materially affect the user or developer experience". There's also an exception process, by which we were able to issue 4.6.1 (and as a result also 4.6.x later; we skipped 4.6.0) as an update for Fedora 14 (which shipped with 4.5.2). (However, unfortunately, we don't know if we'll continue to be able to get those updates through that process. 4.6 was not as seamless as we had expected; the initial testing went very well (in fact our regression tracker was already clear for 4.6.0, but we decided to wait for 4.6.1 anyway), but once pushed, a few complaints popped up.) Still, it's much more likely we'll get one exception for 4.n.0 or 4.n.1 as a whole than separate exceptions for each module, it's just logistically much easier to deal with. But features which don't "materially affect the user or developer experience" are usually snuck through without invoking the exception process; the process is that as long as nobody complains, it's fine. :-) Kevin Kofler >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: No more release schedules.
On Thursday 09 June 2011, Eric Hameleers wrote: > Andreas, how I agree! > > This now, is _exactly_ what I was afraid for when I voiced my concern > about the break-up of this relatively small collection of coherent > source tarballs we are used to work with, into a fragmented and > potentially disconnected set of individual small (project-oriented) > source tarballs. This would mean, KDE as an integrated software > collection is dissolving into a loose collection of software perhaps > not even branded "KDE" anymore. > > Notwithstanding the "frameworks" concept, which sounds appealing, you > should focus on keeping the ecosystem together. Otherwise there will > not be a "KDE SC" soon, but instead "KDE for Slackware, KDE for > Fedora, KDE for Arch, KDE for Windows, KDE for Solaris ..." and every > version will be unpredictably different from the others. This > unpredictability kills the killer concept: that KDE transcends > operating systems. I predict that it will end up like GNOME: one > distro adds Gnome Shell, the next adds Unity, and yet another decides > to stick to a forward-ported old version of the desktop manager. This > surely is not what KDE (and its users!) deserve. +1 My main concern with disparate releases would be that it would be impossible to test all the possible combinations properly. Every distribution would end up with its own combination of versions, with the potential for incompatibilities nobody else can reproduce. We're already seeing enough of those with libraries further down the stack which KDE (the project) has no direct control on, and we've had a couple with the separate kdepim releases too. Having KDE's own packages also released in an uncoordinated fashion would increase the amount of problems by a lot (e.g., in my experience, trying to use an older kdebase-workspace with a newer kdelibs would routinely just crash, even though kdelibs is supposed to be backwards-compatible; we've regularly had Rawhide broken by that if we didn't manage to build kdebase- workspace quickly enough for whatever reason). Please let those separate kdepim releases be the exception (and get kdepim back in sync with the rest of the software compilation for 4.7), not the rule. Another issue is that it would really swamp most distribution's KDE software packaging teams to have to package a new release of package XYZ every day. Yes, freezes can be a problem getting features to our users quickly. But just letting every small module pick its own schedule surely cannot be the solution. (My personal suggestion would actually be to do relaxed freezes as in the 3.5 branch. Then let the module maintainer decide what is stable for a point release and what not, but not proclaim a major release at a random point in time. But that's just another suggestion thrown into the mix.) I realize that this is ultimately the release team's decision, but please do listen to packagers' concerns. Kevin Kofler >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: No more release schedules.
OK, since a lot of context apparently got lost during the message passing, let
me just state my (personal) position clearly:
What I think is acceptable:
* Module X wants feature Y, which is non-invasive and well-tested and does not
change the user experience nor the user interface in a significant way (for
those not using the new feature), backported and released together with KDE SC
4.n.x.
What I think is NOT acceptable:
* Module X wants to release a week before or after all the other modules.
* Every module wants to release at a different date.
* Module X wants to bundle its major feature release M.m.0, which introduces
significant feature changes (maybe even feature regressions, new bugs etc.),
together with the KDE SC bugfix release 4.n.x (x>0). (We've made an exception
for kdepim, but it should not be the rule.)
* KDE releases a new software compilation every month, with some modules
releasing major releases and some modules releasing bugfix releases. (This is a
problem for packagers because either we upgrade nothing and keep all the bugs,
or we upgrade only the modules which released bugfix releases and end up with a
unique combination nobody else is shipping, or we upgrade everything and get
yelled at by the people who don't want feature updates pushed, who sadly have
become dominant even in Fedora.)
(Please note that I do not speak for all packagers, nor even for all Fedora
KDE packagers. They may or may not agree with the above.)
Kevin Kofler
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
