From: Imre Deak <imre.deak@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] dim: Teach fixes subcmd about Cc: stable/-fixes
Date: Wed, 23 Mar 2016 18:29:50 +0200 [thread overview]
Message-ID: <1458750590.3752.9.camel@intel.com> (raw)
In-Reply-To: <20160323162827.GB2510@phenom.ffwll.local>
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
prev parent reply other threads:[~2016-03-23 16:29 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
2016-03-23 16:28 ` Daniel Vetter
2016-03-23 16:29 ` Imre Deak [this message]
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=1458750590.3752.9.camel@intel.com \
--to=imre.deak@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@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 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.