From: Jani Nikula <jani.nikula@intel.com> To: dim-tools@lists.freedesktop.org Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>, jani.nikula@intel.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Rodrigo Vivi <rodrigo.vivi@intel.com> Subject: [MAINTAINER TOOLS] docs: updated rules for topic/core-for-CI commit management Date: Tue, 22 Nov 2022 15:17:14 +0200 [thread overview] Message-ID: <20221122131714.3443238-1-jani.nikula@intel.com> (raw) Introduce stricter rules for topic/core-for-CI management. Way too many commits have been added over the years, with insufficient rationale recorded in the commit message, and insufficient follow-up with removing the commits from the topic branch. New rules: 1. Require maintainer ack for rebase. Have better gating on when rebases happen and on which baselines. 2. Require maintainer/committer ack for adding/removing commits. No single individual should decide. 3. Require gitlab issues for new commits added. Improve tracking for removing the commits. Also use the stronger "must" for commit message requiring the justification for the commit being in topic/core-for-CI. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: dim-tools@lists.freedesktop.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> --- drm-tip.rst | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/drm-tip.rst b/drm-tip.rst index deae95cdd2fe..24036e2ef576 100644 --- a/drm-tip.rst +++ b/drm-tip.rst @@ -203,11 +203,13 @@ justified exception. The primary goal is to fix issues originating from Linus' tree. 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. When in doubt, ask -the maintainers. You'll need to be able to handle any conflicts in non-drm code -while rebasing. +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. -Simply drop fixes that are already available in the new baseline. +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:: @@ -225,11 +227,22 @@ judgement call. Only add or remove commits if you really know what you're doing. When in doubt, ask the maintainers. -Apply new commits on top with regular push. The commit message needs to explain -why the patch has been applied to topic/core-for-CI. If it's a cherry-pick from +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, just remove the commit. This implies ``git rebase --i`` on the current baseline; see directions above. +-i`` on the current baseline; see directions above. Close the associated gitlab +issue when removing commits. -- 2.34.1
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com> To: dim-tools@lists.freedesktop.org Cc: jani.nikula@intel.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>, Rodrigo Vivi <rodrigo.vivi@intel.com>, David Airlie <airlied@gmail.com> Subject: [Intel-gfx] [MAINTAINER TOOLS] docs: updated rules for topic/core-for-CI commit management Date: Tue, 22 Nov 2022 15:17:14 +0200 [thread overview] Message-ID: <20221122131714.3443238-1-jani.nikula@intel.com> (raw) Introduce stricter rules for topic/core-for-CI management. Way too many commits have been added over the years, with insufficient rationale recorded in the commit message, and insufficient follow-up with removing the commits from the topic branch. New rules: 1. Require maintainer ack for rebase. Have better gating on when rebases happen and on which baselines. 2. Require maintainer/committer ack for adding/removing commits. No single individual should decide. 3. Require gitlab issues for new commits added. Improve tracking for removing the commits. Also use the stronger "must" for commit message requiring the justification for the commit being in topic/core-for-CI. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: dim-tools@lists.freedesktop.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> --- drm-tip.rst | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/drm-tip.rst b/drm-tip.rst index deae95cdd2fe..24036e2ef576 100644 --- a/drm-tip.rst +++ b/drm-tip.rst @@ -203,11 +203,13 @@ justified exception. The primary goal is to fix issues originating from Linus' tree. 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. When in doubt, ask -the maintainers. You'll need to be able to handle any conflicts in non-drm code -while rebasing. +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. -Simply drop fixes that are already available in the new baseline. +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:: @@ -225,11 +227,22 @@ judgement call. Only add or remove commits if you really know what you're doing. When in doubt, ask the maintainers. -Apply new commits on top with regular push. The commit message needs to explain -why the patch has been applied to topic/core-for-CI. If it's a cherry-pick from +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, just remove the commit. This implies ``git rebase --i`` on the current baseline; see directions above. +-i`` on the current baseline; see directions above. Close the associated gitlab +issue when removing commits. -- 2.34.1
next reply other threads:[~2022-11-22 13:17 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-22 13:17 Jani Nikula [this message] 2022-11-22 13:17 ` [Intel-gfx] [MAINTAINER TOOLS] docs: updated rules for topic/core-for-CI commit management Jani Nikula 2022-11-22 14:59 ` Daniel Vetter 2022-11-22 14:59 ` [Intel-gfx] " Daniel Vetter 2022-11-22 17:50 ` Rodrigo Vivi 2022-11-22 17:50 ` Rodrigo Vivi 2022-11-22 18:54 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for " Patchwork 2022-11-22 21:53 ` [MAINTAINER TOOLS] " Lucas De Marchi 2022-11-22 21:53 ` [Intel-gfx] " Lucas De Marchi 2022-11-23 9:07 ` Jani Nikula 2022-11-23 9:07 ` [Intel-gfx] " Jani Nikula
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20221122131714.3443238-1-jani.nikula@intel.com \ --to=jani.nikula@intel.com \ --cc=dim-tools@lists.freedesktop.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=rodrigo.vivi@intel.com \ --cc=tvrtko.ursulin@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.