Project

General

Profile

HOWTO merge commits from the integration branch » History » Version 15

Nathan Cutler, 07/24/2015 07:05 PM

1 2 Loïc Dachary
After the [[HOWTO run integration and upgrade tests|tests successfully]] run on the [[HOWTO populate the integration branch|integration branch]]:
2
3 12 Loïc Dachary
h3. Get approval on a backport
4 1 Loïc Dachary
5 12 Loïc Dachary
The backports that were done by someone in the *stable releases* team need to be approved by a developer or a lead, even after successfully passing the relevant teuthology suite. Although a discussion with the developer or the lead could be engaged before testing, it is less work for a busy developer or lead to review a backport that is known to pass integration tests. 
6
7 6 Loïc Dachary
* List the pull requests that have been merged in the integration branch with something like:
8
<pre>
9 1 Loïc Dachary
$ git log --oneline --merges ceph/giant..ceph/giant-backports
10
538d012 Merge 4214: osd/osd_types.cc: 456: FAILED assert(m_seed < old_pg_num)
11
</pre>
12 12 Loïc Dachary
* For each commit in each pull request, lookup the person who merged the backported commit in master
13
** follow the link on the commit hash of the *cherry-pick from* part of the commit message of the backport
14
** follow the link to the pull request that included this commit
15
** the person who merged the pull request was responsible for merging this commit in master
16
* If there are more than one person responsible for merging the commits of a given pull request, pick one (at random if there does not seem to be a reason to chose one rather than the other)
17
* Ask the person responsible for merging the commits, via a comment in the pull request:
18
<pre>
19
@person this backport passed the XXX suite (URL to the pulpito page for the suite), do you think it can be merged ?
20
</pre>
21 15 Nathan Cutler
** Keep in mind that if the responsible person is Josh Durgin, his position is as follows:
22
<pre>
23
Generally you can assume that for trivial backports, or ones with just trivial conflicts, I'm fine with merging them after an rbd suite run.
24
</pre>
25 12 Loïc Dachary
* The person can either merge the pull request (her|him)self or add a comment like LGTM.
26 14 Loïc Dachary
* If the person is unresponsive, the lead can be ping'ed instead.
27 2 Loïc Dachary
28 9 Loïc Dachary
h3. Merge a pull request
29 1 Loïc Dachary
30 9 Loïc Dachary
The backports from the integration branch can be merged (via github so that the pull requests are properly tagged as being merged) into the release branch if:
31
32
* the backport was done by the original developer of the commit
33 13 Loïc Dachary
* the backport was approved by the developer or the lead (see above)
34 9 Loïc Dachary
35
Merging the pull requests goes like this:
36
37 1 Loïc Dachary
* for each pull request merged in the integration branch
38
* go to the github web interface
39
* click on the "Merge button"
40 8 Loïc Dachary
* add the "Reviewed-by:" field to the input box
41 11 Loïc Dachary
* when all pull requests are merged **git log --format='%H %s' --graph ceph/$release..ceph/$release-backports** must not show any commit (i.e. the integration branch must have nothing left because all cherry-picked commits are now found in the $release branch).
42 1 Loïc Dachary
* the $release-backports branch is reset to the $release branch to make it clear that it has been merged (git reset --hard ceph/$release)
43
44 9 Loïc Dachary
h3. Resolving the matching issue
45
46
For each pull request that is merged:
47
48
* go to the corresponding issue that should be listed as a link in the pull request comment
49
* change the status of the issue to *Resolved*
50
51
Note: Since the merge is not from the integration branch, the commit that has been tested won't match the SHA. This is inconvenient when trying to figure out if a mistake has been done. The content of the integration branch should be merged with a script instead of manually via the github web interface to avoid mistakes.