| How do I update a Pull Request? |
| ------------------------------- |
| |
| Often it is necessary to update a Pull Request (PR) before it is merged. When |
| you push to the source topic branch of an open PR, the PR is automatically |
| updated with the new commits. |
| |
| If you need to modify existing commits in the PR (for example following review |
| comments), then use the ``--force`` option when pushing. Any comments that apply |
| to previous versions of the PR are retained in the PR. Sometimes it may be |
| confusing whether comments apply to the current or a previous version of the PR, |
| especially if there are several rounds of rework. In this case, you may be asked |
| to close the PR and create a new one with the latest commits. The new PR should |
| have a version appended to the name (e.g. "My topic v2") and you should create a |
| link to the old PR so that reviewers can easily find previous versions. |
| |
| When the PR is finally merged, you will be given the option of deleting your |
| topic branch. It is recommended you delete this (and any previous topic branch |
| versions) to avoid polluting your fork with obsolete branches. |
| |
| How long will my Pull Request take to merge? |
| -------------------------------------------- |
| |
| This can vary a lot, depending on: |
| |
| * How important the Pull Request (PR) is considered by the TF maintainers. Where |
| possible, you should indicate the required timescales for merging the PR and |
| the impact of any delay. |
| |
| * The quality of the PR. PRs are likely to be merged quicker if they follow the |
| coding guidelines, have already had some code review, and have been |
| appropriately tested. Note that PRs from Arm engineers go through an internal |
| review process before appearing on GitHub, therefore may appear to be merged |
| more quickly. |
| |
| * The impact of the PR. For example, a PR that changes a key generic API is |
| likely to receive much greater scrutiny than a local change to a specific |
| platform port. |
| |
| * How much opportunity for external review is required. For example, the TF |
| maintainers may not wait for external review comments to merge trivial |
| bug-fixes but may wait up to a week to merge major changes, or ones requiring |
| feedback from specific parties. |
| |
| * How many other topics need to be integrated and the risk of conflict between |
| the topics. |
| |
| * Is there a code freeze in place in preparation for the release. Please refer |
| the `release information`_ for more details. |
| |
| * The workload of the TF maintainers. |
| |
| Feel free to add a comment to your PR to get an estimate of when it will |
| be merged. |
| |
| How long will it take for my merged Pull Request to go from ``integration`` to ``master``? |
| ------------------------------------------------------------------------------------------ |
| |
| This depends on how many concurrent Pull Requests (PRs) are being processed at |
| the same time. In simple cases where all potential regressions have already been |
| tested, the delay will be less than 1 day. If the TF maintainers are trying to |
| merge several things over the course of a few days, it might take up to a week. |
| Typically, it will be 1-2 days. |
| |
| The worst case is if the TF maintainers are trying to make a release while also |
| receiving PRs that will not be merged into the release. In this case, the PRs |
| will be merged onto ``integration``, which will temporarily diverge from the |
| release branch. The ``integration`` branch will be rebased onto ``master`` after |
| the release, and then ``master`` will be fast-forwarded to ``integration`` 1-2 |
| days later. This whole process could take up 4 weeks. Please refer the `release |
| information`_ for code freeze dates. The TF maintainers will inform the PR owner |
| if this is going to happen. |
| |
| It is OK to create a PR based on commits that are only available in |
| ``integration`` or another PR, rather than ``master``. There is a risk that the |
| dependency commits will change (for example due to PR rework or integration |
| problems). If this happens, the dependent PR will need reworking. |
| |
| What are these strange comments in my Pull Request? |
| --------------------------------------------------- |
| |
| For example, comments like "Can one of the admins verify this patch?" or "test |
| this please". These are associated with Arm's Continuous Integration |
| infrastructure and can be safely ignored. Those who are curious can see the |
| documentation for `this Jenkins plugin`_ for more details. |
| |
| .. _release information: release-information |
| .. _this Jenkins plugin: https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin |