Hi,
I noticed that there have been 2 recent developments that make it much more
likely for QtWebEngine (and Chromium) to become acceptable for Fedora:
1. Samsung developed a multimedia backend for Chromium that uses GStreamer
instead of FFmpeg:
http://blogs.s-osg.org/announcing-a-new-gstreamer-backend-for-chromium/
2. V8 upstream is working on a bytecode interpreter in their master branch,
which can serve as a fallback for architectures (non-SSE2 i686, secondary
architectures) not supported by the V8 JIT:
https://chromium.googlesource.com/v8/v8/+log/master/src/interpreter
In addition, the people who were at Akademy are reporting that at least the
QtWebEngine upstream is cooperative when it comes to unbundling libraries,
and there has been significant progress on that.
The Qupzilla browser is working on a QtWebEngine-based version, and there
are also first plans (and some experimental code) for a KDE QtWebEngine
browser under the name "Fiber".
I propose that we stick to Konqueror/KWebKitPart at least until it is clear
whether we can get QtWebEngine in. If it works out, then we can plan a move
to Qupzilla, Fiber, or a new browser if one comes out (or maybe even stick
to Konqueror if somebody writes a KWebEnginePart for it). If we KNOW it
doesn't work out, and if we have no way to keep KWebKitPart up to date, THAT
would be the moment to consider non-KDE alternatives (e.g. Firefox).
Shipping Firefox as a one-time stopgap is not worth it when a better
solution may actually be round the corner.
Therefore:
Proposal: For Fedora 23, we stick with Konqueror. Evaluation of QtWebEngine
is still ongoing, due also to recent upstream developments. We will
reconsider the default browser decision after that.
+1 from me for this proposal, obviously.
The other voting members, please vote.
Kevin Kofler