From: Imre Deak <imre.deak@intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH] dim: Teach fixes subcmd about Cc: stable/-fixes
Date: Wed, 23 Mar 2016 17:14:51 +0200 [thread overview]
Message-ID: <1458746091.3752.6.camel@intel.com> (raw)
In-Reply-To: <1458745470-32477-1-git-send-email-daniel.vetter@ffwll.ch>
On ke, 2016-03-23 at 16:04 +0100, Daniel Vetter wrote:
> It's explained in the rules, but tricky. Let's use computers to get it
> right ;-)
>
> Note that Cc: drm-intel-fixes has a few false positives since the
> script can't predict when exactly the feature cutoff is going to be.
> But that's better than losing a few bugfixes.
>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> ---
> dim | 29 +++++++++++++++++++++++++----
> drm-intel.rst | 2 ++
> 2 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/dim b/dim
> index 07ebc56cf36f..d9c1be5a687e 100755
> --- a/dim
> +++ b/dim
> @@ -43,8 +43,6 @@
> # resulting -nightly with the old one. Current the branch must be pushed out
> # first for rebuild-nightly to pick it up, which means the merge can't be
> # fixed any more.
> -# - improve dim tag-contains to automatically print the right Cc: line for
> -# bugfixes. Or maybe add that logic to dim fixes.
>
> # fail on any goof-up
> set -e
> @@ -1149,7 +1147,7 @@ function dim_cat_to_fixup
> function dim_tc
> {
> cd $DIM_PREFIX/$DIM_DRM_INTEL
> - tag=$(git tag --contains $1 | grep ^v | sort -V | head -n 1)
> + local tag=$(git tag --contains $1 | grep ^v | sort -V | head -n 1)
> if [[ -n "$tag" ]]; then
> echo "$tag"
> else
> @@ -1164,9 +1162,32 @@ function dim_tc
>
> function dim_fixes
> {
> - sha1=$1
> + cd $DIM_PREFIX/$DIM_DRM_INTEL
> + local sha1=$1
> +
> git log -1 $sha1 "--pretty=format:Fixes: %H (\"%s\")%n" | \
> sed -e 's/\([0-f]\{12\}\)[0-f]*/\1/'
> +
> + local tag=$(git tag --contains $1 | grep ^v | sort -V | head -n 1)
> + if [[ -n "$tag" ]]; then
> + if echo "$tag" | grep -e "-rc" &> /dev/null ; then
> + echo Cc: drm-intel-fixes@lists.freedesktop.org
> + else
> + echo Cc: stable@vger.kernel.org
> + fi
> + else
> + git fetch $DIM_DRM_INTEL_REMOTE
> + # Check whether it's already in a feature pile tag
> + if git merge-base --is-ancestor $sha1 $DIM_DRM_INTEL_REMOTE/drm-intel-next ; then
> + # Make sure we're in the critical window where we might
> + # need to cherry-pick to dinf. critical window is -rc5
> + # up to end of merge window, hence exclude if in -rc1
> + # through rc-4.
> + if ! git tag | grep ^v | sort -V | tail -n1 | grep -e "-rc[1-4]$" &> /dev/null ; then
> + echo Cc: drm-intel-fixes@lists.freedesktop.org
> + fi
Thanks, this makes things easier.
Could you explain still, the exclusion of rc1-4 timeframe? I understood
that if the regressing commit is already in drm-next (as shown by the
fact that it's contained in drm-intel-next) then we need the -fixes
label regardless. Or do the fixes get upstream via another channel than
drm-intel-fixes during the rc1-4 timeframe?
Thanks,
Imre
> + fi
> + fi
> }
>
> function dim_help
> diff --git a/drm-intel.rst b/drm-intel.rst
> index 89df24b9a0fd..433a33d6b1cc 100644
> --- a/drm-intel.rst
> +++ b/drm-intel.rst
> @@ -171,6 +171,8 @@ recommended format please generate the Fixes: line using ::
>
> $ dim fixes $regressing_commit
>
> +This will also add the correct Cc: line if one is needed.
> +
> If the Cc: or Fixes: was forgotten, you can still reply to the list with that,
> just like any other tags, and they should be picked up by whoever pushes the
> patch.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-03-23 15:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-23 15:04 [PATCH] dim: Teach fixes subcmd about Cc: stable/-fixes Daniel Vetter
2016-03-23 15:14 ` Imre Deak [this message]
2016-03-23 16:28 ` Daniel Vetter
2016-03-23 16:29 ` Imre Deak
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=1458746091.3752.6.camel@intel.com \
--to=imre.deak@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).