Changes between Version 38 and Version 39 of QtWebKitReleases

Timestamp:

Sep 30, 2011, 11:14:58 AM (13 years ago)

Author:

ademar@webkit.org

Comment:

--

QtWebKitReleases

@@ -59 +59 @@
 == 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:
+The process for cherry-picking changes from trunk to a stable branch is semi-automated with the use of {{{cherry-pick-into-release-branch.py}}} and the use of meta-bugs. To keep things working as expected and help the automation, some care must be taken when commiting changes in the branch. 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;
@@ -66 +66 @@
   * 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;
+  * You can use {{{--bugs}}} if you want to cherry-pick some specific bugs or work in a different branch (such as a "devel" or "work-in-progress" branch);
   * 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, 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;
+  * '''Before letting the script add a comment to bugzilla,''' make sure the build is not broken and run some basic tests (run QtTestBrowser, push the changes to a test branch, run the API or 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).
 
+'''Some general tips:'''
+  * You can push the changes to a test branch and ask the bots to build and run the layout tests on it. It's quite useful when making complex changes;
   * 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}}});
+  * Avoid too many changes on bugzilla meta-bugs if they won't help the developers: these changes trigger notification e-mails;
   * 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.