Hi Greg,
On Mon, Mar 13, 2017 at 07:40:50AM +0100, Daniel Vetter wrote:
> On Sun, Mar 12, 2017 at 11:01 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > So if a commit says "cherry-pick", I guess I can always assume it's safe
> > to add, right? If not, _then_ I have to run the "search backwards"
> > logic, right?
> >
> > Ok, let me think about this a bit to see if that's possible to script...
>
> Yes, but it shouldn't be hard to avoid the linear search:
>
> 1. make sure you have the latest linux-next (to make sure all the sha1
> commit-ish resolve to something meaningful). You probably want to do
> that before you board a plane :-)
>
> 2. When you parse an upstream commit that says "commit cherry-picked
> from $original_sha1", then add a git note for $original_sha1 that
> you've seen it already and can ignore it.
>
> 3. Run that script over v4.9..v4.10 to backfill your git notes branch.
>
> 4. Make sure you sync that git notes branch (and if you use git notes
> already, just use a different git notes branch name to avoid
> conflicts).
>
> 5. When you spot a patch with cc: stable, check for a git note that
> says you've looked at it (or one of it's cherry-picks) already, if so,
> silently ignore it.
>
> That should massively drop the ratio of failed patches, at least every
> time I look at your failed patche mail I think they're just
> double-applied ones. There's ofc a few patches that fail to apply, 3
> months of drm/i915 development even wreak the context of simple
> bugfixes sometimes, but most are not (which is btw why you don't get
> replies for most of these).
Are you implementing this? If you need inspiration, we also have a fairly
generic cherry-pick branch command, which filters out duplicated cherry
picks already with:
git log drm-intel-fixes --format=format:%h --after=6months \
--grep="cherry picked .* $commit"
See https://cgit.freedesktop.org/drm-intel/tree/dim?h=maintainer-tools#n713
Please make sure you have something like this ready soon, otherwise we're
going to have this exact conversation again, like we did for the last few
merge windows ... :(
If you can't implement this, then I guess we have to try to avoid
double-tagging stuff with cc: stable. But that will work against 10+ years
of "pls cc: stable bugfixes" training from you. And we'd need to predict
when exactly the merge window cutoff is. Which is going to get it wrong by
1-2 weeks each release, so trying to fix this on our side will be at best
an 80% solution, after 1y of hard re-trainig work :(
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch