[Development] Contributing changes to QtWebKit (was: Re: Building Qt5 from Git failed on Mac OSX)

[Simon Hausmann]

On Friday, December 07, 2012 07:48:44 AM Thiago Macieira wrote:
> On sexta-feira, 7 de dezembro de 2012 11.57.06, Ziller Eike wrote:
> > > git://gitorious.org/qtwebkit/qt5-module.git
> > > 
> > > 
> > > 
> > > which is old, unused and deprecated.
> > 
> > Guys, wasn't there some consensus to announce changes that might destroy
> > people's workflows? This is the first time I hear about qtwebkit now
> > having
> > a different upstream, and of course I still have/had
> > qtwebkit/qt5-module.git because nobody told anyone that we need to run git
> > submodule sync.
> 
> I noticed the new repo in .gitmodules, but up until now I didn't know which
> one was meant for what purpose. What's now the workflow for webkit changes?
> Do they go to WebKit SVN first? Or can we propose changes to this
> repository via Gerrit?

You can propose changes to WebKit through Gerrit, if you'd like. But it must 
be the approver's responsibility of ensuring that the change finds its way 
upstream.

I've reworded our existing paragraph about this in the WebKit wiki to mention 
Gerrit:

https://trac.webkit.org/wiki/QtWebKitReleases#Gettingchangesintoareleasebranch

In other words:

If you're a WebKit reviewer and are looking at a proposed change in Gerrit, 
you can choose to approve the change in Gerrit, forward-port it to trunk, 
review it there and land it, provided that the contributed change is also okay 
to contribute to WebKit. That for example can be the case when you're working 
for the same company as the contributor and both of you are contributing 
changes to Qt under the Company CLA and you're both cleared to contribute to 
WebKit.

Otherwise I think you need to make sure that the proposed change gets 
contributed to WebKit first and reviewed there by a reviewer.

Note that WebKit has its own contribution terms that are visible when 
attaching a patch to WebKit Bugzilla. The "Submit" button turns into ""Agree 
and Submit" below the actual terms.

The easiest path is simply cherry-picking an existing change from upstream, in 
which case I believe any approver in the Qt project feeling comfortable 
reviewing the change should be allowed to approve it.


> Also, can someone say whether we are now accepting bug reports for QtWebKit
> on bugreports.qt-project.org?

The current policy is to report QtWebKit bugs upstream:

    https://trac.webkit.org/wiki/QtWebKitBugs

Given the new, strengthened affinity of the Qt port of WebKit with the (now Open 
Source) Qt project and the availability of the Qt project bug tracker, I'm 
inclined to suggest a change of policy towards the Qt bug tracker, to make 
life easier for the reporter. That however is worth a separate thread of 
discussion (on the webkit-qt mailing list for example).


Simon