Contributing to the API of QtWebKit
If you would like to contribute new functions or classes to the API of QtWebKit, then we ask you to discuss your changes with the rest of the team first. It should not be the responsibility of the WebKit reviewers to learn the rules of Qt API design.There are certain restrictions with regards to binary and source compatibilty as well as rules for consistency in namings and concepts that require us to adjust the existing contribution process slightly for these kinds of changes. Once an API is released we are very limited to the changes we can do to it, so it is very very important to get it right from the beginning.
The process
Make sure you've read QtWebKitContrib
- Create a new bugreport in Bugzilla describing your enhancement. Please use the following template for creating the bug: http://webkit.org/new-qtwebkit-bug
- Make your bug block our meta-bug for pending API enhancements for the next release: QtWebKit 4.7 Pending API This way we can easily keep track of what is left for review and by subscribing to the API meta bug we get email notifications when new APIs are submitted for review.
- Read the sections below about the principles and conventions we apply when designing the API.
- Discuss with us on IRC in #qtwebkit and on the public mailing list at http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt.
- After reaching an agreement, upload your patch(es) and mark them for review, using the standard process of contributiong code: http://webkit.org/coding/contributing.html
- The WebKit reviewers will then review the code, after the API has been approved in step 4 above.
API Style, Conventions and Principles
For QtWebKit we follow the same guidelines that are used for the Qt API. You can review the entire the style guide at http://qt.gitorious.org/qt/pages/ApiDesignPrinciples. Notice that although we follow the same API guidelines, the webkit coding style is different from the one commonly used in Qt and should be respected.
To the users of QtWebKit we promise to maintain binary and source compatibility between minor releases. We share the same policies with KDE and Qt, which are summarized on the KDE website at http://techbase.kde.org/Policies/Library_Code_Policy. Another recommended read is the guide about what kind of API changes are binary compatible and what can be done to work around the imposed limitations: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
