[Intel-gfx] [MAINTAINER TOOLS] docs: updated rules for topic/core-for-CI commit management

[Daniel Vetter]

On Tue, Nov 22, 2022 at 03:17:14PM +0200, Jani Nikula wrote:
> 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 at linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com>
> Cc: David Airlie <airlied at gmail.com>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: intel-gfx at lists.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: dim-tools at lists.freedesktop.org
> Signed-off-by: Jani Nikula <jani.nikula at intel.com>

Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>

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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch