Re: The i915 stable patch marking is totally broken
From: Dave Airlie
Date: Sun Mar 12 2017 - 16:11:56 EST
On 13 March 2017 at 05:44, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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 :-)
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
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.
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