[Intel-gfx] [PATCH] dim: Teach fixes subcmd about Cc: stable/-fixes

Imre Deak imre.deak at intel.com
Wed Mar 23 16:29:50 UTC 2016


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 at intel.com>
> > > Cc: Imre Deak <imre.deak at 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 at lists.freedesktop.org
> > > +		else
> > > +			echo Cc: stable at 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 at 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 at 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


More information about the Intel-gfx mailing list