Changes between Version 32 and Version 33 of QtWebKitReleases


Ignore:
Timestamp:
Sep 26, 2011 7:37:04 AM (13 years ago)
Author:
Ademar Reis
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • QtWebKitReleases

    v32 v33  
    6868  * If there's a conflict, the script will abort. In that case:
    6969    * Solve the conflict ({{{git status, git rm, git add}}}, patch the files manually, etc -- your choice);
    70     * 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.
    71     * Run the script again, it'll detect the new commit and continue as expected.
    72   * '''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.
     70    * 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;
     71    * Run the script again, it'll detect the new commit and continue as expected;
     72  * '''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;
     73  * 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).
    7374
    74   * Avoid adding extra commits in the branch, always prefer cherry-picks to keep cross references with what's in trunk.
     75  * Avoid adding extra commits in the branch, always prefer cherry-picks to keep cross references with what's in trunk (via git-svn-id);
    7576  * 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;
    7677  * In case of doubts, follow the example of what's already there (see {{{git log}}});
    7778  * 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.
    7879
    79 
    80 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:
     80To 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:
    8181
    8282{{{
    8383  $ create-release-notes.py --commits <previous-tag> --email 'foo@bar.com;bar@foo.com'
     84  $ create-release-notes.py --since-last-tag --commits --email webkit-qt@lists.webkit.org --announce
    8485}}}
    8586
    86 Tag the repository {{{git tag -a for an annotated tag}}} and {{{git push --tags}}}).
     87Tag the repository ({{{git tag -a}}} for an annotated tag) and then push the changes ({{{git push --tags}}}).
    8788
    8889== Release Criterias and Timeline ==