Proposal: Defer browser decision until QtWebEngine's fate is clear

[Kevin Kofler]

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