[webkit-qt] Rebasing QtWebKit 2.0 on current trunk?
adawit at kde.org
Sun Jun 13 15:08:55 PDT 2010
If I might chime in here as well... I too second this because of issues
providing patch for upstream issues. For example,
https://bugs.webkit.org/b/34539 shows how upstream code clean up affects
patches provided to fix problems based on qtwebkit-2.0. That is only one
example, but time after time patches created for qtwebkit-2.0 are not cleanly
applicable to trunk for me at least...
On Sunday, June 13, 2010 14:53:16 siddharth.mathur at nokia.com wrote:
> As a developer who often has to do root cause analysis of performance
> issues of QtWebkit-Symbian based products (and potentially upstream
> patches or file bugs), I would find it desirable if were in synch with
> trunk as much as humanely possible. It will save a lot of effort after
> QtWebkit 2.0 is released, and in active use by products. In other words,
> more confidence in explaining why it's behaving the way it is.
> It's a beast. :)
> From: webkit-qt-bounces at lists.webkit.org
> [mailto:webkit-qt-bounces at lists.webkit.org] On Behalf Of Kling Andreas
> (Nokia-D/Oslo) Sent: Sunday, June 13, 2010 2:15 PM
> To: webkit-qt at lists.webkit.org
> Subject: [webkit-qt] Rebasing QtWebKit 2.0 on current trunk?
> Given the currently slipping schedules, should we perhaps consider rebasing
> QtWebKit 2.0 on current WebKit trunk?
> Apple pushed some nice speed and memory improvements before releasing
> Safari 5 and these could really benefit us, not to mention the 4 months of
> "regular" work that WebKit has had since we originally branched off.
> Some examples:
> Yes, we could obviously cherry-pick these changes, but given the current
> timeframe, I personally think that rebasing (and re-entering stabilization
> mode) could be worthwhile.
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
More information about the webkit-qt