* [PATCH] dim: Teach fixes subcmd about Cc: stable/-fixes
@ 2016-03-23 15:04 Daniel Vetter
2016-03-23 15:14 ` Imre Deak
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Vetter @ 2016-03-23 15:04 UTC (permalink / raw)
To: Intel Graphics Development; +Cc: Jani Nikula, Daniel Vetter
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
+ 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.
--
2.8.0.rc3
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] dim: Teach fixes subcmd about Cc: stable/-fixes
2016-03-23 15:04 [PATCH] dim: Teach fixes subcmd about Cc: stable/-fixes Daniel Vetter
@ 2016-03-23 15:14 ` Imre Deak
2016-03-23 16:28 ` Daniel Vetter
0 siblings, 1 reply; 4+ messages in thread
From: Imre Deak @ 2016-03-23 15:14 UTC (permalink / raw)
To: Daniel Vetter, Intel Graphics Development; +Cc: Jani Nikula
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] dim: Teach fixes subcmd about Cc: stable/-fixes
2016-03-23 15:14 ` Imre Deak
@ 2016-03-23 16:28 ` Daniel Vetter
2016-03-23 16:29 ` Imre Deak
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Vetter @ 2016-03-23 16:28 UTC (permalink / raw)
To: Imre Deak; +Cc: Jani Nikula, Daniel Vetter, Intel Graphics Development
On Wed, Mar 23, 2016 at 05:14:51PM +0200, Imre Deak wrote:
> 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?
If a broken commit is in drm-next but not in -rc/Linus' tree, and rc5
isn't out there yet then the fix will go into Dave's tree with the next
feature pull. Jani doesn't yet do special -fixes pulls for drm-next at
that point. Only once the feature pull train has stopped, then Jani opens
drm-intel-next-fixes (and hence needs the Cc: tags to figure out what to
cherry-pick). If we tag everything as Cc: we just create busywork for Jani
for no gain.
Broken patches which are in upstream ofc always need a Cc: line, but
that's all handled by the first line.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] dim: Teach fixes subcmd about Cc: stable/-fixes
2016-03-23 16:28 ` Daniel Vetter
@ 2016-03-23 16:29 ` Imre Deak
0 siblings, 0 replies; 4+ messages in thread
From: Imre Deak @ 2016-03-23 16:29 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Jani Nikula, Daniel Vetter, Intel Graphics Development
On ke, 2016-03-23 at 17:28 +0100, Daniel Vetter wrote:
> On Wed, Mar 23, 2016 at 05:14:51PM +0200, Imre Deak wrote:
> > 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?
>
> If a broken commit is in drm-next but not in -rc/Linus' tree, and rc5
> isn't out there yet then the fix will go into Dave's tree with the next
> feature pull. Jani doesn't yet do special -fixes pulls for drm-next at
> that point. Only once the feature pull train has stopped, then Jani opens
> drm-intel-next-fixes (and hence needs the Cc: tags to figure out what to
> cherry-pick). If we tag everything as Cc: we just create busywork for Jani
> for no gain.
Ah, ok that explains:
Acked-by: Imre Deak <imre.deak@intel.com>
> Broken patches which are in upstream ofc always need a Cc: line, but
> that's all handled by the first line.
Yes, that was clear already.
> -Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-03-23 16:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-23 15:04 [PATCH] dim: Teach fixes subcmd about Cc: stable/-fixes Daniel Vetter
2016-03-23 15:14 ` Imre Deak
2016-03-23 16:28 ` Daniel Vetter
2016-03-23 16:29 ` Imre Deak
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).