Project

General

Profile

After the tests successfully run on the integration branch:

Get approval on a backport

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.

The upgrade suite must always pass before asking for approval because it may reveal problems related to rados, CephFS, rgw or rbd.

  • List the pull requests that have been merged in the integration branch with something like:
    $ git log --oneline --merges ceph/giant..ceph/giant-backports
    538d012 Merge 4214: osd/osd_types.cc: 456: FAILED assert(m_seed < old_pg_num)
    
  • For each commit in each pull request, lookup the person who merged the backported commit in master
    • follow the link on the commit hash of the cherry-pick from part of the commit message of the backport
    • if the commit starts with something like https://github.com/Abhishekvrshny/ceph replace it with https://github.com/ceph/ceph otherwise the link to the pull request won't show
    • follow the link to the pull request that included this commit
    • the person who merged the pull request was responsible for merging this commit in master
  • 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)
  • Ask the person responsible for merging the commits, via a comment in the pull request:
    @person this backport passed the XXX suite (URL to the pulpito page for the suite), do you think it can be merged ?
    
    • Keep in mind that if the responsible person is Josh Durgin, his position is as follows:
      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.
      
  • The person can either merge the pull request (her|him)self or add a comment like LGTM.
  • Assign the pull request to the person so that it shows up in (her|his) list of assigned pull requests.
  • If the person is unresponsive, the lead can be ping'ed instead.

Merge a pull request

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:

  • the backport was done by the original developer of the commit
  • the backport was approved by the developer or the lead (see above)

Merging the pull requests goes like this:

  • for each pull request merged in the integration branch
  • go to the github web interface
  • click on the "Merge button"
  • add the "Reviewed-by:" field to the input box
  • 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).
  • the $release-backports branch is reset to the $release branch to make it clear that it has been merged (git reset --hard ceph/$release)

Resolving the matching issue

ceph-workbench backport-set-release --git-remote ceph --git-directory $HOME/software/ceph/ceph ---github-token $github_token --redmine-key $redmine_key

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.