Message-ID: <20170312215215.GA30510@kroah.com>
Date:   Sun, 12 Mar 2017 22:52:15 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Dave Airlie <airlied@...il.com>
Cc:     Daniel Vetter <daniel.vetter@...el.com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        stable@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: The i915 stable patch marking is totally broken

On Mon, Mar 13, 2017 at 06:11:12AM +1000, Dave Airlie wrote:
> On 13 March 2017 at 05:44, Greg KH <gregkh@...uxfoundation.org> wrote:
> > Hi Daniel and Jani and other members of the i915-commit-cabal,
> >
> > I've mentioned this a few times to Daniel in the past (like at the last
> > kernel summit), but the way you all are handling the tagging of patches
> > for inclusion in stable kernel releases is totally broken and causing me
> > no end of headaches.
> >
> > It's due to your "you have a branch, you have a branch, you all have a
> > branch!" model of development.  You have patches that end up flowing in
> > to Linus's trees multiple times for different releases.  Now git is
> > smart enough to handle most of this, and you end up doing a lot of
> > hand-fixing for other merge issues, but when it comes to doing the
> > stable kernel work, none of that means squat.  All I get to see is when
> > a patch lands in Linus's tree, and if that patch has a "cc: stable@"
> > marking, then I look at it.
> >
> > But, when a patch hits Linus through multiple branches, that means I see
> > it multiple times, usually months apart in timeframe.  This is
> > especially bad during the -rc1 merge window when all of the old work you
> > all did for the past 3 months hits Linus, which includes all of the old
> > bugfixes that were already in the previous kernel release.
> >
> > I think there were over 25 different patches in -rc1 that hit this
> > issue.  Maybe more, maybe less, I don't know, I'm giving up at this
> > point, I wasted over 2 hours trying to figure out a way to do this in an
> > automated way, or by hand, or something else to deal with all of these
> > rejections or "fuzz merge" which really was a duplicate.
> >
> > And the joy of your "cherry-picked from 12345..." messages, with git
> > commit ids that are no where to be found in Linus's tree at all, is
> > totally annoying as well, why even have this if it doesn't mean
> > anything?  I sure can't use it.
> >
> > Not to mention all of the build-breakages, and normal "fails to apply"
> > that you all end up with, your driver subsystem has the largest instance
> > of those as well, and build-breakages are the worst, as they cause my
> > process to come to a screeching halt while I have to bisect to find the
> > broken patch.  Given the lack of patches that people actually send me
> > when I send in the "FAILED" emails, I'm guessing that you all don't care
> > that much about stable kernels either, which is fine, as again, I'm
> > giving up on your driver.
> >
> > So, either you all only mark a patch _ONCE_.  Or come up with some way
> > for me to determine, in an automated way that a patch is already in
> > Linus's older release, or just don't mark anything and send me a
> > hand-curated list of git commit ids, or patches in mbox form (like DaveM
> > does), or something else you all come up with.  What is happening now is
> > not working at all, and as of now, I'm going to just drop all i915
> > patches with a cc: stable marking on the floor.
> >
> > Congrats on being the first subsystem that I've had to blacklist from my
> > stable patch workflow :(
> >
> > greg "35k feet above India and grumpy" k-h
> 
> What happened to, I won't ask subsystem maintainers to do any extra work :-)

Well, when they cause me extra work, or problems, I'm allowed to complain :)

> But I'm not sure why the model doesn't break for others, surely some subsystems
> realise after committing patches to -next, they really are more urgent
> so put them into a -fixes pull earlier, but can't rebase -next. The
> cherry-pick tag should have the info vs the -next tree that Linus is
> pulling in the next merge window, it would be a bit difficult to do a
> cherry-pick to -fixes from a branch Linus has already pulled.

Nope, no other subsystem does it like the i915 driver does.  Only rarely
does a patch for stable come in multiple times.  The i915 driver does it
way too often.

Why don't the maintainers know which tree to put them in when they are
submitted?  As an example, if I get a patch that needs to go to Linus, I
put it in my usb-linus branch, and when it hits a -rc release, I then
merge that -rc back into my usb-next branch.  So I end up with about 2-3
merges to -rc every release, which isn't bad and doesn't cause any
duplication issues.

Seems that most other subsystems also do this as well.

> I don't think there is anything incorrect in the model, and it
> certainly has nothing to do with "the branch model" or whatever you
> are alluding to there.  The branches are pretty simple, a -next and a
> -fixes with occasional -next-fixes for merge window, is it just the
> sheer number of patches that go to -next and get pulled into -fixes
> that overwhelms you?

25-30 patches marked for stable ended up in 4.11-rc1 that were already
in 4.10.0.  And I think this was way less than what happened in
4.12-rc1.  It's hard to determine that a patch really is a duplicate, or
if it just doesn't apply for some other reason.  So much so that I dread
the drm stable patches, which should not happen.

thanks,

greg k-h

Powered by blists - more mailing lists