Changes between Version 19 and Version 20 of QtWebKitReleases

Timestamp:

Mar 4, 2011, 9:32:29 AM (14 years ago)

Author:

Ademar Reis

Comment:

minor

QtWebKitReleases

@@ -73 +73 @@
 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 ==
+== Procedures for 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:
@@ -80 +80 @@
   * Downloand and setup [http://gitorious.org/qtwebkit/tools qtwebkit/tools] (change PATH and PYTHONPATH as necessary);
   * Check [wiki:UsingGitWithWebKit] for valuable tips and tricks;
+  * Set your username and password in git-config (see instructions in the link above);
   * 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:
@@ -85 +86 @@
     * 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;
+  * '''Before letting the script add a comment to bugzilla, '''make sure the build is not broken and run some basic tests (run QtTestBrowser, the API tests -- your choice), 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.
+  * If the patch is a backport, you're free to add your own changelog, but make sure there are at least two lines there: one with the bug title and one with the full bug URL;
+  * In case of doubts, follow the example of what's already there (see {{{git log}}}).
 
 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: