| 74 | |
| 75 | == Tools to help on cherry-picking and weekly releasing == |
| 76 | |
| 77 | 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: |
| 78 | |
| 79 | * Clone the [http://gitorious.org/webkit/ qtwebkit git/svn mirror] and keep it up to date; |
| 80 | * Downloand and setup [http://gitorious.org/qtwebkit/tools qtwebkit/tools] (change PATH and PYTHONPATH as necessary); |
| 81 | * Check [wiki:UsingGitWithWebKit] for valuable tips and tricks; |
| 82 | * 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; |
| 83 | * If there's a conflict, the script will abort. In that case: |
| 84 | * Solve the conflict ({{{git status, git rm, git add}}}, patch the files manually, etc -- your choice); |
| 85 | * Commit the changes, '''keeping the original changelog from the original git commit;''' |
| 86 | * Run the script again, it'll detect the new commit and continue as expected. |
| 87 | * 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; |
| 88 | * Avoid adding extra commits in the branch, always prefer cherry-picks to keep cross references with what's in trunk. |
| 89 | |
| 90 | 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: |
| 91 | |
| 92 | {{{ |
| 93 | $ create-release-notes.py --commits <previous-tag> --email 'foo@bar.com;bar@foo.com' |
| 94 | }}} |
| 95 | |
| 96 | Don't forget to tag the repository (and {{{git push --tags}}}) before making an announcement. |