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.
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.
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.
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.