Hotfixes in topic/core-for-CI¶
While the topic/core-for-CI branch lives in drm-intel, it’s primarily relevant for drm-tip. It’s merged to drm-tip in nightly.conf after the feature and fixes branches, and mostly contains hotfixes to unblock the Intel CI pending proper fixes. A typical example is a patch or a cherry-pick from another subsystem to an issue showing up in -rc1, while waiting for the fix to show up in the DRM subsystem via regular merges.
Access¶
Anyone with drm-intel commit access has access to rebase, add, and remove commits. Please follow the directions below.
Rebasing¶
topic/core-for-CI is a rebasing and force pushed branch. Please rebase it on top of Linus’ release or -rc tags. Rebasing on top of drm-next should be a rare, justified exception. The primary goal is to fix issues originating from Upstream. Issues that would need drm-next or other DRM subsystem tree as baseline should be fixed in the offending DRM subsystem tree.
Only rebase the branch if you really know what you’re doing. You’ll need to be able to handle any conflicts in non-drm code while rebasing.
Always ask for maintainer ack before rebasing. IRC ack is sufficient.
Simply drop fixes that are already available in the new baseline. Close the associated gitlab issue when removing commits.
Force pushing a rebased topic/core-for-CI requires passing the --force
parameter to git:
$ dim push-branch topic/core-for-CI --force
You may also need to pass -f
to dim:
$ dim -f push-branch topic/core-for-CI --force
Adding and Removing Commits¶
Preferrably send a patch or a revert with subject prefix “[topic/core-for-CI]” to the intel-gfx and/or intel-xe mailing lists to get the CI results on the change. However, in some cases, a direct push may be required to get CI back online ASAP. It’s a judgement call.
Only add or remove commits if you really know what you’re doing. When in doubt, ask the maintainers.
Always ask for maintainer/committer ack before adding/removing commits. IRC ack
is sufficient. Record the Acked-by:
in commits being added.
Apply new commits on top with regular push. The commit message must explain why
the patch has been applied to topic/core-for-CI. If it’s a cherry-pick from
another subsystem, please reference the commit with git cherry-pick -x
option. If it’s a patch from another subsystem, please reference the patch on
the mailing list with Link:
tag.
New commits always need an associated gitlab issue for tracking purposes. The
goal is to have as few commits in topic/core-for-CI as possible, and we need to
be able to track the progress in making that happen. Reference the issue with
References:
tag. Add the core-for-CI
label to the issue. (Note: Do not
use Closes:
because the logic here is backwards; the issue is having the
commit in the branch in the first place.)
Instead of applying reverts, you may also just remove the commit. This implies
git rebase -i
on the current baseline; see directions above. Close the
associated gitlab issue when removing/reverting commits.