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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
