06.06.2016, 16:54, "Lars Knoll" <[email protected]>: > Hi Konstantin, > > I’d be happy to host this project here on qt-project.org (and that includes > of course both source code and bug tracking) :)
Thank you! > > I don’t think it is a problem that the set of supported platforms is > different from Qt WebKit in 5.6, this would have evolved in any way due to > changes in the upstream project. I can also see why it would be hard to > support certain things such as webkit2 on Windows (it has been difficult to > support that in the past). > > I don’t even see a larger problem with continuing the development in the > existing qtwebkit repository under three conditions: First, the branch names > should make it clear that this is the new effort and not the older Qt WebKit > that is being shipped with 5.6. Secondly the project needs to continue to > either have full binary compatibility with the old QtWebKit in this case or > bump the major .so version. A drop-in replacement (ie. Keeping BC) would be > preferred if that’s possible. Thirdly, the documentation needs to be very > explicit about the feature delta between old and new versions. There is one technical reason _against_ re-using existing qtwebkit repository: these two repos do not have any shared history. Repository [1] is a direct fork of upstream, while repository [2] uses squashed history and does not include LayoutTests. If we want to reuse [2] to hold code from [1] and don't want to bloat it with several extra GiBs of data overnight, the only reasonable startegy is to import snapshots, like it was done in old days. Having such stripped-down repository will probably be beneficial for users (and maybe occasional contributors as well) who won't need to deal with full-blown WebKit repo, but for actual development full repository is needed. There are other concerns which may affect your decision: 1. We use CMake-based build system, most of which is shared with other Webkit ports. This is purely pragmatic decision, aimed at maintenance cost reduction [3]. 2. We use the same licensing policy as WebKit, i.e. BSD + LGPLv2 and no LGPLv3 [4] 3. Our plan is to use stable branches of WebKitGTK as a base of our stable branches, e.g. now it is 2.12 branch [5]. This may cause lack of alignment with Qt release schedule sometimes. [1] https://github.com/annulen/webkit [2] http://code.qt.io/cgit/qt/qtwebkit.git/ [3] https://github.com/annulen/webkit/wiki/FAQ [4] https://github.com/annulen/webkit/wiki/Licensing [5] Reasons to use WebKitGTK instead of Apple's stable branch: * we share more code with GTK than with Apple, especially on *nix * on embedded, Apple is strongly focused on ARM64 whle GTK supports wider range of platforms * GTK creates stable branches 2x more often than Apple => less lagging behind ToT > > Cheers, > Lars > > On 04/06/16 22:40, "Development on behalf of Thiago Macieira" > <[email protected] on behalf of > [email protected]> wrote: > >> Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu: >>> 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should >>> it be versioned? >>> >>> Pros: >>> * It is a drop-in replacement for QtWebKit, >> >> Please don't. You can use the same soname if you are binary compatible, but >> please call the module / project something different to indicate that it's >> different from the previous effort. We cannot give the impression that it is >> a >> continuation if it doesn't get as wide support as the old one had and feature >> parity. >> >> PS: Windows CE is dropped from 5.8, so you don't have to worry about it. >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> _______________________________________________ >> Development mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
