Changes between Version 18 and Version 19 of QtWebKitReleases

Timestamp:

Mar 4, 2011 9:19:29 AM (13 years ago)

Author:

Ademar Reis

Comment:

misc fixes + a section about the qtwebkit/tools used for release-management

QtWebKitReleases

@@ -66 +66 @@
   * The patch has a ChangeLog entry;
   * The changes are public and live on a gitorious branch, rebased with the targeted release;
-  * Patches that affect the API:
-    * A unit test included needs to be included;
-    * The API needs to be private, unless there's a concensus that the API is final, reviewed and will land unchanged in the trunk;
   * Patches that affect WebCore should have a layout test included, although this is not mandatory;
   * At least one WebKit reviewer signs off on the patch and no other reviewer objects;
-  * The bug is linked from it's corresponding JIRA item at http://bugreports.qt.nokia.com/browse/QTWEBKIT;
-  * The bug is marked to block the tracker bug for patches pending trunk inclusion: https://bugs.webkit.org/show_bug.cgi?id=32653.
+  * The bug is marked to block the tracker bug for patches pending trunk inclusion: https://bugs.webkit.org/show_bug.cgi?id=32653;
+  * Any exception has to be first discussed in the public mailing list;
 
 After the release we have to make a concentrated effort in reducing the number of exceptional patches, by reviewing the changes in the bugs that the tracker bug ([https://bugs.webkit.org/show_bug.cgi?id=32653 32653]) depends on.
+
+== Tools to help on cherry-picking and weekly releasing ==
+
+The process for cherry-picking changes from trunk to a stable branch is semi-automated. To keep things working as expected, some care must be taken when commiting changes there. Below are the basic steps and the commands involved:
+
+  * Clone the [http://gitorious.org/webkit/ qtwebkit git/svn mirror] and keep it up to date;
+  * Downloand and setup [http://gitorious.org/qtwebkit/tools qtwebkit/tools] (change PATH and PYTHONPATH as necessary);
+  * Check [wiki:UsingGitWithWebKit] for valuable tips and tricks;
+  * From the branch where you want to cherry-pick a change ({{{git new-workdir}}} is your friend), run {{{cherry-pick-into-release-branch.py}}} (see {{{--help}}}). This script will parse bugzilla, ask for cherry-picks, add comments and remove bugs from their trackers;
+  * If there's a conflict, the script will abort. In that case:
+    * Solve the conflict ({{{git status, git rm, git add}}}, patch the files manually, etc -- your choice);
+    * Commit the changes, '''keeping the original changelog from the original git commit;'''
+    * Run the script again, it'll detect the new commit and continue as expected.
+  * Make sure the build is not broken and run some basic tests (build, run QtTestBrowser, the API tests -- your choice) '''before letting the script add a comment to bugzilla''' (so that if there's something broken, you can fix it and {{{git commit --amend}}} the changes before a reference is added to bugzilla;
+  * Avoid adding extra commits in the branch, always prefer cherry-picks to keep cross references with what's in trunk.
+
+To create release notes reports (similiar to the ones posted weekly in the [http://www.google.com.br/search?q=qtwebkit+developer+journal QtWebKit Developer Journal]), run the {{{create-release-notes.py}}} (see {{{--help}}}). Usually it looks like this:
+
+{{{
+  $ create-release-notes.py --commits <previous-tag> --email 'foo@bar.com;bar@foo.com'
+}}}
+
+Don't forget to tag the repository (and {{{git push --tags}}}) before making an announcement.
 
 == Proposal for release testing ==