[Development] QtWebKit is coming back (part 2)
Konstantin Tokarev
annulen at yandex.ru
Tue May 9 19:05:30 CEST 2017
08.05.2017, 15:22, "Lars Knoll" <lars.knoll at qt.io>:
>> On 8 May 2017, at 13:37, Jani Heikkinen <jani.heikkinen at qt.io> wrote:
>>
>> Couple of comments below
>>
>> br,
>> Jani
>>
>>> -----Original Message-----
>>> From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt-
>>> project.org] On Behalf Of Konstantin Tokarev
>>> Sent: maanantaina 8. toukokuuta 2017 12.56
>>> To: Tuukka Turunen <tuukka.turunen at qt.io>; Oswald Buddenhagen
>>> <Oswald.Buddenhagen at qt.io>; development at qt-project.org
>>> Subject: Re: [Development] QtWebKit is coming back (part 2)
>>>
>>> 05.05.2017, 14:15, "Konstantin Tokarev" <annulen at yandex.ru>:
>>>> 05.05.2017, 10:04, "Tuukka Turunen" <tuukka.turunen at qt.io>:
>>>>> Hi,
>>>>>
>>>>> There has also been some interest also for getting Qt WebEngine to be
>>> released much faster cycle than Qt – exactly due to the security update need.
>>> Even if we succeed in making substantially more frequent Qt patch releases
>>> than before, it may still be better if user would have the option to update
>>> some parts (like QWE) more frequently or out of sync.
>>>
>>>>> I think what we should consider, is to perhaps carve out Qt WebEngine
>>> from Qt as well. Not immediately, but for Qt 6 we should anyway consider
>>> our current setup of essential and add-on modules. For the html5 engine
>>> there is the matter of binary size in addition to release frequency. This is not
>>> to say that we would stop developing html5 engine – just that it might be
>>> beneficial to do in in different way than currently.
>>>
>>>>> For new updated Qt Webkit, perhaps we could have it as a separate item
>>> that works on top of Qt 5.9 for those to use it who prefer it over Qt
>>> WebEngine. After it has existed for a while as a separate item, it is also easier
>>> to know what would be the best way to get it into a Qt release – or is that
>>> even necessary.
>>>
>>>> BTW, let me bring an attention to the elephant in the room.
>>>>
>>>> Yes, my fork of QtWebKit existed for a while as a separate item. But
>>>> it was never and "official" successor, and even me myself was warning
>>>> people that it is not an official replacement as some features are not yet
>>> restored.
>>>
>>>> However, now there is no valid reason to keep using QtWebKit contained
>>>> in 5.9 and dev branches anymore. Feature parity is achieved to the
>>>> level of drop-in replacement that can be applied system-wide. Still many
>>> people see 5.9 branch as a source of truth.
>>>
>>>> We need to convey a message to wide audience that old QtWebKit should
>>>> no longer be used, and that there is a new release that should be used
>>>> instead. Not only with Qt 5.9.0, but also with older Qt releases, down to Qt
>>> 5.2.x if people still use it (e.g., Ubuntu 14.04).
>>>
>>>> This is why question about version numbers and related stuff is
>>>> important. If this is not done, it doesn't matter at all whatever tag
>>>> names will be picked and what schedules will be followed.
>>>
>>> Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even does
>>> not exist, I think it should be to make exceptions in branch and release
>>> management policies for
>>> 5.9 and 5.9.0 branches, solely to resolve situation described above.
>>
>> Actually 'old ' webkit is in our builds but not part of official releases, see e.g https://testresults.qt.io/coin/integration/qt/qt5/tasks/1494068162
>> That is because we have agreed to keep it working and deliver src packages for the releases as well. Not part of official release but in addition.
>
> As I said in my other mail, we could easily drop those unsupported packages. Maybe quickly check whether the 5.8 packages compile against Qt 5.9. If they do, there’s no need at all to release packages that are the same, but remove the option of using the new version number for the updated engine.
>>> I propose the following plan:
>>>
>>> 1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond to
>>> "alpha" release, that has feature parity, but is not yet guaranteed to be
>>> polished enough.
>> To be honest, I don't want to do this now. From release schedule point of view it is just too late, we cannot risk our Qt 5.9.0 release schedule because of this. At this point 5.10 should be enough. For me it is ok if you want to add TP/Alpha etc in http://download.qt.io/community_releases/5.9/ but being part of official ci builds in '5.9.x' it is too risky.
>
> Yes, we can’t couple this to our Qt 5.9 release. It clearly comes too late for that.
In the light of your announcement about 5.9 becoming LTS, I think it's especially important to get QtWebKit update in 5.9 branch. See below.
>
> In addition, I am not convinced it’s a too good idea, we were never really happy with that tight coupling for our web engine(s) in the past. So I’d propose we rather first try to figure out if we can keep those decoupled from a releasing perspective. This might create some challenges in how we handle things from a packaging/CI side, but working through those items might be helpful in the longer term, and something we could then start considering for web engine as well.
QtTools module, that uses QtWebKit for Assistant, requires QtWebKit to be present in Qt5 superbuild. Yes, official builds use QtTextBrowser currenly, but 1) configuration with QtWebKit is in CI and 2) it was a source of many complaints, because people used to rely on availability of rich HTML renderer in Assistant.
QtWebView module requires QtWebEngine on Linux and Windows in the same manner. Besides that, QtWebView currently does not support Windows/MinGW, as well as non-Linux POSIXish systems, that somewhat breaks its premise about providing browser component that works everywhere. Adding QtWebKit backend would fill this gap.
So, while web engines don't need tight coupling with the rest of Qt, they are not leaf products and therefore have to be part of the superbuild, which implies being submodules of qt5.git with current state of things.
And, taking into account Oswald's reply about our inability to use custom branch names in qt5 submodules, leads to requirement of updating 5.9 branch in qtwebkit in order to avoid proliferation of obsolete code.
>From my side, I promise to investigate all possible problems in CI resulting from wip/next -> 5.9 merge as soon as possible, and do final release polishing before Qt 5.9.1 freeze.
>
> Cheers,
> Lars
>
>>> 2. Host sources and binaries of QtWebKit corresponding to 5.9.0-alpha
>>> release at http://download.qt.io/community_releases/5.9/
>> This should be OK as well
>>
>>> 3. For dev branch, follow all necessary procedures to change status of
>>> QtWebKit and make it work for Qt 5.10 without any schedule exceptions.
>>>
>>> [1] http://doc.qt.io/qt-5/qtmodules.html
>>>
>>>>> Yours,
>>>>>
>>>>> Tuukka
>>>>>
>>>>> On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev"
>>> <development-bounces+tuukka.turunen=qt.io at qt-project.org on behalf of
>>> annulen at yandex.ru> wrote:
>>>
>>>>> 04.05.2017, 19:35, "Oswald Buddenhagen"
>>> <oswald.buddenhagen at qt.io>:
>>>>> > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev
>>> wrote:
>>>>> >> 03.05.2017, 17:27, "Sergio Martins" <sergio.martins at kdab.com>:
>>>>> >> > On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>>>> >> >> Remaining question is versioning. While it's fine to dub
>>>>> current
>>>>> >> >> release "5.9" (but not 5.0, because we will have another
>>>>> WebKit update
>>>>> >> >> in 5.10 time frame), using Qt versions in QtWebKit has
>>> downsides:
>>>>> >> >>
>>>>> >> >> 1. It is not clear if 5.N+1 ships with the same WebKit
>>>>> branch as 5.N,
>>>>> >> >> or is updated
>>>>> >> >> 2. It makes people believe that QtWebKit 5.N should be
>>>>> used with Qt
>>>>> >> >> 5.N only. QtWebKit supports wide range of Qt versions
>>>>> (starting from
>>>>> >> >> 5.2 as of now), and can be used e.g. as security update in
>>>>> Linux
>>>>> >> >> distro that does not normally update Qt version during its life
>>> cycle.
>>>>> >> >>
>>>>> >> >> Any comments?
>>>>> >> >
>>>>> >> > If Qt and QtWebKit will have different release schedules
>>>>> then that
>>>>> >> > numbering would indeed confuse people.
>>>>> >>
>>>>> >> What about choice of new versioning scheme?
>>>>> >>
>>>>> >> I'm leaning towards "6.0.0" number, because it's larger than
>>>>> any 5.x and makes it
>>>>> >> clear that versioning is different now. Bug fixes will
>>>>> increment patch version (6.0.x),
>>>>> >> WebKit updates minor version (6.1.x etc), API/ABI breaking
>>>>> changes - major
>>>>> >> verison (7.0 etc.)
>>>>> >>
>>>>> >> Qt5 supermodule will be tracking latest available stable
>>>>> branch. When release branch
>>>>> >> is created (e.g. 5.10.0), corresponding patch release branch
>>>>> is created in qtwebkit
>>>>> >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt
>>> release branches.
>>>>> >>
>>>>> >> However, I'm not sure about two things:
>>>>> >> 1) Is it possible to have custom branch names in qtwebkit
>>>>> repository, or there need to
>>>>> >> be virtual 5.10 etc. branches to match other modules?
>>>>> >> 2) What about bug tracking in JIRA? I would like to keep
>>>>> existing issues as is, but assing
>>>>> >> new release numbers to items fixed in new releases
>>>>> >
>>>>> > i'll say outright that you can't be part of the qt supermodule
>>>>> and yet
>>>>> > have independent releases. while that was the plan once upon a
>>>>> time, the
>>>>> > whole release infrastructure simply doesn't deliver, and even
>>>>> just
>>>>> > diverging branch names are a pita (proved by enginio). as a
>>>>> product, qt
>>>>> > is as monolithic as ever.
>>>>>
>>>>> Understood: no custom branch/tag names in official repo.
>>>>>
>>>>> >
>>>>> > your release cycle concerns seem to be centered around the
>>>>> webkit
>>>>> > backend, and you can deal with that by lowering the
>>>>> compatibility
>>>>> > guarantees of patch releases at this level, i.e. take the
>>>>> freedom to
>>>>> > upgrade webkit in a patch release. as long as you keep qt's
>>>>> api/abi
>>>>> > compat promises, you're fine. that means that you will not be
>>>>> able to
>>>>> > expose new webkit features until the next minor release if
>>>>> they require
>>>>> > new api.
>>>>>
>>>>> That's probably fine with me, except 2 moments that seem to require
>>> "out of band" releases:
>>>
>>>>> 1. Something should be done with current release. As I said,
>>>>> it's not an option to postpone
>>>>> it to 5.10, however it also cannot be released as 5.9.1 because
>>>>> there are API additions
>>>>> which I don't want to revert (in particular because these APIs
>>>>> were already shipped by
>>>>> Linux distros that chose to provide TP4 and TP5). Also there is
>>>>> a change in QDataStream
>>>>> format of QWebHistory.
>>>>>
>>>>> 2. Security updates. WebKitGTK team provides several patch
>>>>> releases for each stable branch,
>>>>> which contain only fixes for bugs and security issues, and
>>>>> towards the end of release life cycle
>>>>> they became primarily security updates. I think we should be
>>>>> able to release such updates ASAP,
>>>>> by making up some tag name and scheduling custom build against
>>> newest patch release of Qt.
>>>
>>>>> > _______________________________________________
>>>>> > Development mailing list
>>>>> > Development at qt-project.org
>>>>> > http://lists.qt-project.org/mailman/listinfo/development
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Konstantin
>>>>> _______________________________________________
>>>>> Development mailing list
>>>>> Development at qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>>
>>>> --
>>>> Regards,
>>>> Konstantin
>>>> _______________________________________________
>>>> Development mailing list
>>>> Development at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>
>>> --
>>> Regards,
>>> Konstantin
>>> _______________________________________________
>>> Development mailing list
>>> Development at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
--
Regards,
Konstantin
More information about the Development
mailing list