Message-ID: <20170312194440.GA32007@kroah.com>
Date:   Sun, 12 Mar 2017 20:44:40 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Daniel Vetter <daniel.vetter@...el.com>,
        Jani Nikula <jani.nikula@...ux.intel.com>
Cc:     intel-gfx@...ts.freedesktop.org, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: The i915 stable patch marking is totally broken

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

Powered by blists - more mailing lists