1Frequently-Asked Questions (FAQ) 2================================ 3 4How do I update my changes? 5--------------------------- 6 7Often it is necessary to update your patch set before it is merged. Refer to the 8`Gerrit Upload Patch Set documentation`_ on how to do so. 9 10If you need to modify an existing patch set with multiple commits, refer to the 11`Gerrit Replace Changes documentation`_. 12 13How long will my changes take to merge into ``integration``? 14------------------------------------------------------------ 15 16This can vary a lot, depending on: 17 18* How important the patch set is considered by the TF maintainers. Where 19 possible, you should indicate the required timescales for merging the patch 20 set and the impact of any delay. Feel free to add a comment to your patch set 21 to get an estimate of when it will be merged. 22 23* The quality of the patch set. Patches are likely to be merged more quickly if 24 they follow the coding guidelines, have already had some code review, and have 25 been appropriately tested. 26 27* The impact of the patch set. For example, a patch that changes a key generic 28 API is likely to receive much greater scrutiny than a local change to a 29 specific platform port. 30 31* How much opportunity for external review is required. For example, the TF 32 maintainers may not wait for external review comments to merge trivial 33 bug-fixes but may wait up to a week to merge major changes, or ones requiring 34 feedback from specific parties. 35 36* How many other patch sets are waiting to be integrated and the risk of 37 conflict between the topics. 38 39* If there is a code freeze in place in preparation for the release. Please 40 refer the :ref:`Release Processes` document for more details. 41 42* The workload of the TF maintainers. 43 44How long will it take for my changes to go from ``integration`` to ``master``? 45------------------------------------------------------------------------------ 46 47This depends on how many concurrent patches are being processed at the same 48time. In simple cases where all potential regressions have already been tested, 49the delay will be less than 1 day. If the TF maintainers are trying to merge 50several things over the course of a few days, it might take up to a week. 51Typically, it will be 1-2 days. 52 53The worst case is if the TF maintainers are trying to make a release while also 54receiving patches that will not be merged into the release. In this case, the 55patches will be merged onto ``integration``, which will temporarily diverge from 56the release branch. The ``integration`` branch will be rebased onto ``master`` 57after the release, and then ``master`` will be fast-forwarded to ``integration`` 581-2 days later. This whole process could take up 4 weeks. Please refer to the 59:ref:`Release Processes` document for code freeze dates. The TF maintainers 60will inform the patch owner if this is going to happen. 61 62It is OK to create a patch based on commits that are only available in 63``integration`` or another patch set, rather than ``master``. There is a risk 64that the dependency commits will change (for example due to patch set rework or 65integration problems). If this happens, the dependent patch will need reworking. 66 67What are these strange comments in my changes? 68---------------------------------------------- 69 70All the comments from ``ci-bot-user`` are associated with Continuous Integration 71infrastructure. The links published on the comment are not currently accessible, 72but would be after the CI has been transitioned to `trustedfirmware.org`_. 73 74-------------- 75 76*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* 77 78.. _Gerrit Upload Patch Set documentation: https://review.trustedfirmware.org/Documentation/intro-user.html#upload-patch-set 79.. _Gerrit Replace Changes documentation: https://review.trustedfirmware.org/Documentation/user-upload.html#push_replace 80.. _trustedfirmware.org: https://www.trustedfirmware.org/ 81