Changes between Version 32 and Version 33 of QtWebKitReleases

Timestamp:

Sep 26, 2011, 7:37:04 AM (13 years ago)

Author:

Ademar Reis

Comment:

--

QtWebKitReleases

@@ -68 +68 @@
   * 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 with a standard {{{git commit}}} command. It'll keep the changelog from the original git commit plus a list of conflicting files, but '''you'll have to add a line''' "Author: Foo Bar <foobar@whatever.com>", otherwise you'll be listed as the commit author.
-    * Run the script again, it'll detect the new commit and continue as expected.
-  * '''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.
+    * Commit the changes with a standard {{{git commit}}} command. It'll keep the changelog from the original git commit plus a list of conflicting files, but '''you'll have to add a line''' "Author: Foo Bar <foobar@whatever.com>", otherwise you'll be listed as the commit author;
+    * Run the script again, it'll detect the new commit and continue as expected;
+  * '''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, the layout 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;
+  * Sometimes a fix has follow-up commits to rebaseline layout tests or add other minor fixes. You can find them in the git log of trunk. The script won't detect these, but it can be done by looking for the bug ID and the SVN revision (to-do).
 
-  * Avoid adding extra commits in the branch, always prefer cherry-picks to keep cross references with what's in trunk.
+  * Avoid adding extra commits in the branch, always prefer cherry-picks to keep cross references with what's in trunk (via git-svn-id);
   * 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}}});
   * Check [https://lists.webkit.org/pipermail/webkit-qt/2011-May/001560.html this thread about the usage of meta-bugs] on the !QtWebKit Mailing List.
 
-
-To create release notes reports (similiar to the ones posted weekly to the [http://lists.qt.nokia.com/pipermail/qtwebkit-announce/ QtWebKit Announcement Mailing List]), run the {{{create-release-notes.py}}} (see {{{--help}}}). Usually it looks like this:
+To create release notes reports (similiar to the ones posted weekly to the [http://lists.qt.nokia.com/pipermail/qtwebkit-announce/ QtWebKit Announcement Mailing List]), run the {{{create-release-notes.py}}} (see {{{--help}}}). Some examples:
 
 {{{
   $ create-release-notes.py --commits <previous-tag> --email 'foo@bar.com;bar@foo.com'
+  $ create-release-notes.py --since-last-tag --commits --email webkit-qt@lists.webkit.org --announce
 }}}
 
-Tag the repository {{{git tag -a for an annotated tag}}} and {{{git push --tags}}}).
+Tag the repository ({{{git tag -a}}} for an annotated tag) and then push the changes ({{{git push --tags}}}).
 
 == Release Criterias and Timeline ==